É uma boa prática usar suprimir avisos no seu código?

Eu uso os métodos acima @SuppressWarnings("unchecked")e @SuppressWarnings("null")acima para deixar o código compilar sem nenhum aviso, mas tenho minhas dúvidas. Encontrou esta pergunta sobre o Stackoverflow . Jon Skeet escreveu uma resposta que acho intrigante.

De acordo com ele,

Às vezes, os genéricos Java simplesmente não permitem que você faça o que deseja e você precisa informar efetivamente ao compilador que o que você está fazendo realmente será legal no momento da execução.

Mas e se houver uma chance de uma exceção ser lançada? Suprimir avisos não é uma má ideia, então? Eu não deveria estar ciente dos lugares onde os problemas poderiam surgir?

Além disso, e se alguém modificar meu código posteriormente e adicionar alguma funcionalidade questionável sem remover o SuppressWarnings? Como isso pode ser evitado e / ou existe outra alternativa para isso?

Devo estar usando @SuppressWarnings("unchecked")e @SuppressWarnings("null")?

Atualização # 1

No que diz respeito às conversões de tipo não verificado, de acordo com esta resposta (apontada por @gnat nos comentários abaixo), é necessário suprimir esses avisos.

Muitas bibliotecas Java indispensáveis ​​nunca foram atualizadas para eliminar a necessidade de previsões inseguras. Suprimir esses avisos é necessário para que outros avisos mais importantes sejam notados e corrigidos.

No caso de suprimir outros avisos, ainda em uma área um pouco cinza.

Atualização # 2

Conforme o Oracle Docs (também mencionado por algumas respostas abaixo):

Por uma questão de estilo, os programadores sempre devem usar esta anotação no elemento mais profundamente aninhado em que é eficaz. Se você deseja suprimir um aviso em um método específico, anote esse método em vez de sua classe.

Para mim, o objetivo de suprimir avisos é manter um "atestado de integridade" para o seu projeto. Se você sabe que toda a sua base de código é compilada de maneira limpa, é imediatamente óbvio quando alguém faz algo errado que faz com que o primeiro aviso apareça na lista de problemas. Você pode então corrigir o erro ou suprimi-lo se puder provar que é falso.

Mas se você tiver 21 avisos, é muito mais provável que você ignore o 22º quando alguém o causar, e não verifique se é inofensivo. Isso significa que os problemas podem surgir na sua base de código e você nunca notará.

Os avisos são itens de informação úteis. Preste atenção aos que falam a verdade e filtre os que não falam. Não permita que as pessoas misturem os dois tipos, para que você perca seu sistema de alerta precoce.

Editar

Eu provavelmente deveria esclarecer que suprimir um aviso que tenha mérito é uma coisa tola de se fazer. Um atestado de saúde que você obteve por trapaça obviamente não vale nada. Dada a escolha, você sempre deve corrigir o problema que o compilador percebeu em vez de apenas fechar os olhos para ele. No entanto, há áreas em que o compilador não pode ter certeza se algo será um problema ou não (os genéricos de Java são uma dessas áreas) e a melhor opção é revisar cada instância e suprimir o aviso nesse local específico. do que desativar completamente essa classe de aviso e potencialmente perder um genuíno.

Suprimir avisos é algo que precisa ser feito com extremo cuidado.

Um aviso significa: O compilador encontrou algo que parece desonesto. Isso não significa que é desonesto, apenas parece com o compilador. Às vezes, você tem um código perfeitamente correto e emite um aviso. Às vezes, você o corrige modificando levemente seu código. Às vezes, o compilador possui algum recurso especificamente para esse fim. Por exemplo, onde

if (x = someFunction ()) { ... }

dá um aviso, mas

if ((x = someFunction ())) { ... }

não. No primeiro caso, um aviso assumindo que você possivelmente quis dizer == e não =. No segundo caso, nenhum aviso, porque os parênteses extras informam ao compilador "Eu sei o que estou fazendo". Melhor, claro, seria

if ((x = someFunction ()) != 0) { ... }

ou usando duas linhas.

E, às vezes, muito raramente, há casos em que seu código está bom, mas você não consegue escrevê-lo de uma maneira que seja aceita sem aviso. Nesse caso muito, muito raro, você desativa um aviso para essa instrução e o liga imediatamente depois. Esse é o último recurso. E você desabilita apenas esse aviso específico, nenhum outro.

No entanto, algumas pessoas simplesmente desativam os avisos para se livrar deles, porque são preguiçosos demais para descobrir e corrigir o motivo de um aviso legítimo primeiro. Ou eles nem tentam escrever código livre de avisos. Isso é uma coisa extremamente prejudicial a se fazer.

A supressão de aviso para um método inteiro é suspeita. Melhor suprimir os avisos para a linha específica, com um comentário . por exemplo

@SuppressWarnings("unchecked") Foo foo = (Foo)object; // Using old library requires this cast