Зачем? «Всегда объявляйте определенные пользователем исключения как окончательные»

Question

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

Я работаю над фреймворком, и у меня есть одно общее корневое исключение (скажем, FrameworkGenericException), а для других исключений я просто извлекаю их из корневого исключения. Так что у меня есть иерархия исключений для фреймворка. Я мог бы расширить иерархию, но, как мне кажется, это предупреждение говорит мне не иметь такую ​​иерархию, а определять их индивидуально. Итак, в какую сторону мне идти, каковы ваши комментарии?

Answer 1

Это, вероятно, стандартная практика для них: объявлять классы как окончательные, если они не должны наследоваться, а также они, вероятно, думают, что все ваши исключения не будут расширены.

Однако,в вашем случае я думаю, что было бы хорошо сделать одно общее исключение и исключить из него все остальные.Скажем, у вас есть:

public void frameworkMethod() throws IllegalDataException, InvalidCommandException;

, где эти исключения являются подклассами FrameworkException.Тогда вы могли бы обрабатывать исключения немного проще.

try {
    frameworkMethod();
} catch (FrameworkException ex) {
    logger.log(Level.SEVERE, "An exception occured!", ex);

    if (ex instanceof IllegalDataException) {
        // Do something to recover
    } else if (ex instanceof InvalidCommandException) {
        //Inform the user
    } //And so on...
}

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

Answer 2

Держу пари, что это сообщение исчезнет, ​​если вы сделаете свое обобщенное исключение абстрактным.Вы будете следовать за другим уважаемым объектно-ориентированным гуру, Скоттом Мейером:

Сделайте абстрактные классы не листовыми.для всей вашей структуры.Какое необычное поведение вы внедрили в это, что все дети будут наследовать сверх того, что происходит от java.lang.Throwable?

Я думаю, что SpecialBusinessException, перекрывающий четыре конструктора из java.lang.RuntimeException - это достаточно.Какой смысл в иерархии?Держу пари, что он плоский и широкий, с одним корневым классом.Зачем?

Answer 3

Странно. Гугл показывает только один документ с такими словами - твой вопрос:)

В моих проектах вполне нормально иметь определяемых пользователем предков для всех исключений. Несколько лет разработки в этом стиле, с этим ничего особенного пока не связано.

Answer 4

Дело в том, что инструмент статического анализа в основном сканирует ваш код на предмет нарушений (как считает автор инструмента) «лучших практик».В этом случае обычно считается «наилучшей практикой» иметь очень мелкие иерархии исключений.

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

try
{
    return fetchDataFromFile();
}
catch(FileNotFoundException)
{
    return defaultData;
}

В этом случае вы поймали FileNotFoundException, потому что вы хотите вернуть «данные по умолчанию», когда файл не найден.В этой ситуации вы обычно перехватываете специфический класс исключений - потому что это единственный тип исключения, который вы знаете, как обрабатывать (например, если fetchDataFromFile выдает другое исключение, вы не хотите, чтобы оновернуть данные по умолчанию.

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

try
{
    doStuff();
catch(Exception e)
{
    logException(e);
    notifyUser(e);
}

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

Есть очень немного ситуаций, когда вам нужно что-то делать.

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

Answer 5

Я никогда не слышал об этой рекомендации, и она не имеет никакого смысла для меня.

Какой инструмент вы используете?Я попробовал поискать в Google это сообщение и получил НОЛЬ хитов, кроме вашего ТАКОГО вопроса.Попытки других поисков в попытке «использовать мудрость сети» также не дали мне ничего очевидного.

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