Является ли хорошей практикой использование предупреждений в вашем коде?

Я использую @SuppressWarnings("unchecked")и в @SuppressWarnings("null")основном выше методы, чтобы код компилировался без каких-либо предупреждений, но у меня есть сомнения. Нашел этот вопрос Stackoverflow . Джон Скит написал ответ, который я нахожу интригующим.

По его словам,

Иногда дженерики Java просто не позволяют вам делать то, что вы хотите, и вам нужно эффективно сообщить компилятору, что то, что вы делаете, действительно будет законным во время выполнения.

Но что, если есть шанс, что будет выдано исключение? Не является ли подавление предупреждений плохой идеей? Разве я не должен знать о местах, где могут возникнуть проблемы?

Кроме того, что если кто-то еще позже изменит мой код и добавит некоторые сомнительные функции, не удаляя SuppressWarnings? Как этого можно избежать и / или есть ли другая альтернатива этому?

Должен ли я использовать @SuppressWarnings("unchecked")и @SuppressWarnings("null")?

Обновление № 1

Что касается непроверенных приведений типов, согласно этому ответу (указанному @gnat в комментариях ниже), подавление этих предупреждений необходимо.

Многие необходимые библиотеки Java никогда не обновлялись, чтобы исключить необходимость небезопасных типов. Подавление этих предупреждений необходимо, чтобы другие более важные предупреждения были замечены и исправлены.

В случае подавления других предупреждений, все еще в некоторой серой области.

Обновление № 2

Согласно Oracle Docs (также упоминается в некоторых ответах ниже):

В целях стиля программисты всегда должны использовать эту аннотацию для наиболее глубоко вложенного элемента, где она эффективна. Если вы хотите подавить предупреждение в конкретном методе, вы должны аннотировать этот метод, а не его класс.

Для меня весь смысл подавления предупреждений состоит в том, чтобы поддерживать «чистый счет здоровья» для вашего проекта. Если вы знаете, что вся ваша кодовая база скомпилирована правильно, это сразу становится очевидным, когда кто-то делает что-то не так, что вызывает появление первого предупреждения в списке проблем. Затем вы можете исправить ошибку или устранить ее, если докажете, что она ложная.

Но если у вас есть 21 предупреждение для начала, гораздо более вероятно, что вы пропустите 22-е предупреждение, когда кто-то его вызвал, и вы не убедитесь, что оно безвредно. Это означает, что проблемы могут закрасться в вашу кодовую базу, и вы никогда не заметите.

Предупреждения являются полезными элементами информации. Убедитесь, что вы обращаете внимание на тех, кто говорит правду, и отфильтровываете тех, кто не говорит. Не позволяйте людям смешивать два вида, чтобы вы потеряли свою систему раннего предупреждения.

редактировать

Я, наверное, должен пояснить, что подавлять предупреждение, которое имеет свои достоинства, глупо. Чистый счет здоровья, который вы получили путем обмана, очевидно, ничего не стоит. Учитывая выбор, вы всегда должны исправлять проблему, замеченную компилятором, а не просто закрывать на это глаза. Тем не менее, существуют области, в которых компилятор не может быть уверен, что что-то будет проблемой или нет (дженерики Java являются одной из таких областей), и там лучше выбрать просмотр каждого такого экземпляра, а затем скорее подавить предупреждение в этом конкретном месте. чем вообще отключить этот класс предупреждений и потенциально пропустить настоящий.

Подавление предупреждений - это то, что нужно делать с особой осторожностью.

Предупреждение означает: компилятор нашел что-то, что выглядит странно. Это не значит, что это хитро, это просто похоже на компилятор. Иногда у вас есть код, который прекрасно работает и выдает предупреждение. Иногда вы исправляете это, слегка изменяя свой код. Иногда компилятор имеет какую-то особенность специально для этой цели. Например, где

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

дает предупреждение, но

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

не делает. В первом случае предупреждение, если вы имели в виду ==, а не =. Во втором случае нет предупреждения, потому что лишние скобки сообщают компилятору: «Я знаю, что я делаю». Лучше конечно было бы

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

или используя две строки.

И иногда, очень редко, бывают случаи, когда ваш код в порядке, но вы не можете написать его так, как это принято без предупреждения. В этом очень, очень редком случае вы отключаете предупреждение для этого оператора и включаете его сразу после этого. Это последнее средство. И вы только отключаете это конкретное предупреждение, никаких других.

Тем не менее, некоторые люди просто отключают предупреждения, чтобы избавиться от предупреждений, потому что они слишком ленивы, чтобы сначала выяснить и устранить причину обоснованного предупреждения. Или они даже не пытаются написать код, который не содержит предупреждений. Это крайне вредно для здоровья.

Подавление предупреждения для всего метода является подозрительным. Лучше подавить предупреждения для конкретной строки с комментарием . например

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