Почему мы должны писать пользовательские классы исключений в Java

Question

Какова цель создания пользовательских классов исключений, когда в основном то, что они делают, одинаково. Для например, NullPointerException:

class NullPointerException extends RuntimeException { 
     private static final long serialVersionUID = 5162710183389028792L; 


     public NullPointerException() { 
      super(); 
     } 


     public NullPointerException(String s) { 
      super(s); 
     } 
} 

Это основной шаблон для большинства классов исключений, которые я видел и создал.

Одна из целей, о которых я могу думать, заключается в обработке этих исключений. Но тогда это может быть основано на Исключительном сообщении ?. В основном мы пишем один код обработки для каждого типа исключения. Я знаю, что есть «исключения».

Но есть ли что-нибудь еще? Разве это не повторяется, когда меняется только название класса?

Также есть ли классы исключения JDK, у которых есть код, чем этот?

Answer 1

Это в основном обращение с различными исключениями по-разному. Скажем, вы можете выполнить некоторую другую операцию над ArrayIndexOutOfBoundsException, чем исключение NumberFormatException.

или более четко

}catch (ArrayIndexOutOfBoundsException ex){ 
//operation 1 
}catch (NumberFormatException ex){ 
//operation 2 
} 

Answer 2

Я могу назвать несколько причин:

• Имея несколько классов исключений позволяет программисту быть конкретными в своих catch пунктах, и только перехватывать исключения, они заботятся о и знать, что делать.
• Класс исключения может содержать информацию об ошибке, вызвавшей исключение. Например, ArrayIndexOutOfBoundsException несет индекс жестового массива, а исключения SQL имеют тенденцию нести коды ошибок и сообщения, специфичные для конкретной базы данных.
• Спецификации исключения - это исключение списка классы - могут использоваться для проверки правильности во время компиляции.

Answer 3

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

Answer 4

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

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

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

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

Если у вас есть полностью настраиваемое исключение, которое никогда не должно быть улавливано уловом суперкласса, которое всегда должно иметь конкретный блок catch, то вы напрямую распространяете Exception.

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

Answer 5

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

Как это сделать:

1. Определить новый класс исключений, поэтому имя класса говорит, что происходит
2. Определение unifed/общий класс исключений, который оборачивает code, message или другую информацию. code может рассказывать, что происходит.

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

Answer 6

1. Мы будем иметь свободу, чтобы добавить еще несколько методов в нашем классе Exception, который помогает клиенту как rootCauseOfException(), описание(), решение(), предложения() и т.д. Можно сослаться ссылке ниже:
   https://stackoverflow.com/a/22698673

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

3. Вы также можете маскировать некоторые конфиденциальные данные, такие как ip, порт и т. Д. Перед отправкой на клиентскую сторону. Если пользовательские исключения не используются, некоторые конфиденциальные данные могут просочиться в slient.

4. Вы можете предоставить свое собственное сообщение об исключении, которое может быть легко понято клиентом, а не сообщением об исключении java, которое иногда может быть трудно понять.