java.lang.Exception против вашего собственного исключения

Question

В какой момент вы создадите свой собственный класс исключения против использования java.lang.Exception? (Все время? Только если он будет использоваться за пределами пакета? Только если он должен содержать расширенную логику? И т. Д.)

Answer 1

Я думаю, вам нужно задать себе небольшой вопрос: «Какое преимущество создает новый исключение дайте мне или разработчикам, которые используют мой код? " На самом деле единственным преимуществом, которое оно дает вам или другим людям, является способность справиться с этим исключением. Это похоже на очевидный ответ, но на самом деле это не так. Вы должны обрабатывать исключения, из которых вы можете разумно восстановить. Если исключение, которое вы бросаете, является поистине фатальной ошибкой, почему разработчики могут ошибаться?

Более углубленное обсуждение: Custom exceptions: When should you create them?

Answer 2

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

Answer 3

В большинстве случаев не имеет смысла создавать свой собственный класс исключений.

В начинающих программистах существует тенденция создавать свой собственный класс исключений, чтобы они могли использовать имя, которое более указывает на тип ошибки. Таким образом, вы найдете такие классы, как FTPInitializationException, DAOFactoryException и т. Д., Хотя такие исключения не обрабатываются иначе, чем стандартные исключения. Это явно анти-шаблон, которого следует избегать.

Answer 4

Старт всегда с использованием общих классов исключений, а затем, когда потребность, похоже, обрабатывает его специально, измените его.

1. При создании метода в первый раз, просто разрешите исключения.

2. Если есть исключения, которые должны быть обработаны, они могут быть либо определены в бросках, либо завернуты в какое-либо исключение во время выполнения, либо могут быть обернуты собственным исключением. Во многих случаях я предпочитаю исключения во время выполнения. Определение определения throws следует избегать, пока не возникнет необходимость в нем с точки зрения API.

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

Цель состоит в том, чтобы избежать дополнительной работы, прежде чем знать, что необходимо.

Answer 5

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

Answer 6

Причина, в отношении которой один:

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

В принципе, если кто-то должен написать:

catch(ExistingException e) { 
    if({condition}) { 
    { some stuff here} 
    } 
    else { 
    { different stuff here} 
    } 
} 

Вы, вероятно, хотите, чтобы написать определенное расширение; catch Исключение соответствия более ясное, чем условные, ИМХО.

Помните: ваш новый Исключение может быть подкласс RuntimeException

Причина два:

API консолидации. Если вы пишете интерфейс и у вас есть несколько реализаций, вполне возможно, что они будут называть разный API, с целым букетом различных нетканых RuntimeExceptions брошенным:

interface MyInterface { 
    void methodA(); 
} 

class MyImplA { 
    void methodA() throws SQLException { ... } 
} 

class MyImplB { 
    void methodA() throws IOException { ... } 
} 

Вы действительно хотите MyInterface.methodA бросить SQLException и IOException? Возможно, тогда имеет смысл обернуть возможные исключения в пользовательском исключении. Это снова может быть RuntimeException. Или даже само RuntimeException ...

Answer 7

Я бы воспользовался исключениями из Java API, когда это исключение относится к API. Но если возникает исключительная ситуация, которая уникальна для моего собственного API, я создам для нее исключение. Например, если у меня есть объект Range с двумя свойствами min и max и инвариант min < = max, тогда я создам исключение InvalidRangeException.

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

Answer 8

Я считаю, что:

catch (Exception e) { 
    ... 
} 

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

Почему:

try { 
    if(myShape.isHidden()) { 
     throw new Exception(); 
    } 
    // More logic 
} catch (Exception e) { 
    MyApp.notify("Can't munge a hidden shape"); 
} 

Так вы попробуете это, и из-за ошибки кодирования, myShape равна нулю. Исключение NullPointerException получает, когда среда выполнения пытается отменить myShape. Этот код сообщает о скрытой форме, когда он должен указывать нулевой указатель.

Либо сделайте свое собственное исключение, либо найдите подходящее специализированное исключение в API. Это не так, как если бы исключение Exception или RuntimeException было обременительным.

Answer 9

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

Answer 10

Программное обеспечение фиксирует значение.

Практически отсутствуют причины для изъятия существующего исключения: JVM уже делает это за вас. Ваша версия их исключения не очень точна, и бросать «Исключение» тоже не имеет смысла.

Возможно, у вас есть DataFormatException из-за алгоритма синтаксического анализа, который вы написали. Это, однако, редко.

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

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

Правило Python, переведенное на Java, предназначено для определения любых уникальных исключений на уровне пакета. [В Python они предлагают исключения на уровне «модуля», что неточно переводит на Java.]