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

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

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

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

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

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

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

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

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

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

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

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

Мое собственное практическое правило:

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

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

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

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

Reusing preexisting exceptions has several benefits. Chief among these, it makes your API easier to learn and use because it matches established conventions with which programmers are already familiar [my emphasis, not Bloch's]. A close second is that programs using your API are easier to read because they aren't cluttered with unfamiliar exceptions. Finally, fewer exception classes mean a smaller memory footprint and less time spent loading classes.

The most commonly reused exception is IllegalArgumentException. This is generally the exception to throw when the caller passes in an argument whose value is inappropriate. For example, this would be the exception to throw if the caller passed a negative number in a parameter representing the number of times some action were to be repeated.

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

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

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

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

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

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

Не ешьте исключения, кидайте их 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");
}