Каково общее правило для создания исключения в Java?

Question

Я был в обеих ситуациях:

• Создание слишком большого количества пользовательских исключений
• Использование слишком большого общего класса исключений

В обоих случаях проект начался нормально, но вскоре стал излишним обслуживанием (и рефакторингом).

Итак, какова лучшая практика создания собственных исключительных классов?

Answer 1

Специалисты по Java написали пост о Исключениях в Java , и в нем они перечисляют несколько "лучших практик" для создания исключений, кратко изложенных ниже:

• Не пишите собственные исключения (есть много полезных исключений, которые уже являются частью Java API)

• Напишите полезные исключения (если вам нужно написать свои собственные исключения, убедитесь, что они предоставляют полезную информацию о возникшей проблеме)

Answer 2

Не делайте того, что делали разработчики в моей компании. Кто-то создал исключение [sic] InvalidArguementException, параллельное java.lang.IllegalArgumentException, и теперь мы используем его (буквально) в сотнях классов. Оба указывают, что методу был передан недопустимый или неподходящий аргумент. Поговорим об отходах ...

Джошуа Блох описывает это в Руководстве по эффективному языку программирования Java [моя библия первого взгляда на лучшие практики] Глава 8. Исключения Пункт 42: Пользу от использования стандартных исключения . Вот немного из того, что он говорит,

Повторное использование существующих исключений имеет несколько преимуществ. Главным из них является упрощение изучения и использования вашего API, поскольку соответствует установленным соглашениям, с которыми программисты уже знакомы [ мой акцент, а не Блоха. Второй момент заключается в том, что программы, использующие ваш API, легче читать, потому что они не загромождены незнакомыми исключениями. Наконец, меньшее количество классов исключений означает меньший объем памяти и меньше времени, затрачиваемого на загрузку классов.

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

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

Будьте дружелюбны с программистами, которые должны поддерживать ваш код в будущем.

Answer 3

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

try {
     doIt();
} catch (ExceptionType1 ex1) {
     // do something useful
} catch (ExceptionType2 ex2) {
     // do the exact same useful thing that was done in the block above
}

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

Answer 4

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

Это мое правило.

Answer 5

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

Одним из советов было бы создание исключений по мере необходимости, и, если станет очевидно, что один тип исключения является дубликатом другого, проведите рефакторинг кода, объединив их. Конечно, это помогает, если некоторые мысли начинают структурировать исключения с самого начала. Но, как правило, используйте пользовательские исключения для всех случаев, которые не соответствуют 1: 1 существующим, специфичным для ситуации исключениям.

С другой стороны, NullPointerException с и IndexOutofBoundsException с на самом деле часто могут быть подходящими. Однако не перехватывайте их (за исключением регистрации), поскольку они являются ошибкой программирования, что означает, что после их выброса программа находится в неопределенном состоянии.

Answer 6

При создании собственного исключения:

• Все исключения должны быть потомками класса Throwable

• Если вы хотите написать проверенное исключение, которое автоматически применяется правилом обработки или объявления, вам необходимо расширить Класс исключения

• Если вы хотите написать исключение времени выполнения, вам нужно расширить класс исключений времени выполнения.

Answer 7

Мое эмпирическое правило:

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

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

Answer 8

Не ешьте исключения, бросайте их https://stackoverflow.com/a/921583/1097600

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

IllegalStateException
UnsupportedOperationException
IllegalArgumentException
NoSuchElementException
NullPointerException

Бросить непроверенные исключения.

Пример

public void validate(MyObject myObjectInstance) {
    if (!myObjectList.contains(myObjectInstance))
        throw new NoSuchElementException("object not present in list");
}