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

Ответ 1

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

Более подробное обсуждение: Пользовательские исключения: когда их следует создавать?

Ответ 2

Причина одна:

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

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

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

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

Помните: ваш новый Exception может быть подклассом 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...

Ответ 3

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

catch (Exception e) {
   ...
}

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

Почему:

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

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

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

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

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

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

Ответ 7

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

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

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

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

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

Ответ 8

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

Ответ 9

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

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

Ответ 10

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

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