Это хорошая практика для подавления предупреждений?

Question

Иногда, когда я пишу Java в Eclipse, я пишу код, который генерирует предупреждения. Типичным является то, что я получаю при расширении класса Exception:

public class NumberDivideException extends Exception {

    public NumberDivideException() {
        super("Illegal complex number operation!");
    }

    public NumberDivideException(String s) {
        super(s);
    }
} // end NumberDivideException

Предупреждение:

Сериализуемый класс NumberDivideException не объявляет статическое окончательное поле serialVersionUID типа long.

Я знаю, что это предупреждение вызвано моей неспособностью ... ну, это сказано прямо выше. Я мог бы решить это, включив serialVersionUID, но это одночасовое крошечное задание для школы; Я не планирую сериализацию в ближайшее время ...

Другой вариант, конечно, разрешить Eclipse добавить @SuppressWarnings("serial").

Но каждый раз, когда моя мышь наводит курсор на опцию Suppress, я чувствую себя немного виноватым.

Для программирования в целом полезно ли подавлять предупреждения?

(Также, как дополнительный вопрос, является ли добавление «сгенерированного» * ​​1022 * типа serialVersionUID = -1049317663306637382L; правильным способом добавления serialVersionUID, или мне нужно определить число другим способом?)

---

РЕДАКТИРОВАТЬ: После просмотра ответов, кажется, мой вопрос может быть немного спорным ... Извините! Слишком поздно для меня, чтобы удалить хотя ...

Answer 1

В конкретном случае затмения, а не подавления предупреждений по мере их появления, я предпочитаю настраивать затмение для выдачи предупреждений, которые мне интересны, и автоматически игнорировать все экземпляры тех, которые мне не нужны. Смотри Windows -> Настройки -> Java -> Компилятор -> Ошибка / Предупреждения

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

Answer 2

Очень приятно, что код компилируется без предупреждений - и когда вы его получите, он выделяется и может предупредить вас о проблеме в коде

Answer 3

Вы должны подавлять предупреждения ТОЛЬКО если вы абсолютно уверены в том, что делаете и было бы лучше документировать подобные вещи для будущих изменений (например, комментарии к документу java)

таким образом, вы скрываете предупреждения, которые, как вы знаете, не вызовут проблем, и можете сосредоточиться на тех, которые вызовут у вас проблемы

Answer 4

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

Однако для школьных заданий вас часто просят заново изобрести колесо / выполнить тривиальные задачи, и поэтому вы не должны испытывать беспокойство по поводу «взлома» вещей вместе. Если, конечно, вы не оценили стиль кодирования ...

Answer 5

Везде, где это возможно, подавлять предупреждения только в определенной строке или, самое большее, в конкретном файле.

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

(Я не знаю достаточно об Eclipse, чтобы это произошло - это общий принцип, применимый ко всем языкам.)

Answer 6

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