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

Обоснуйте тот:

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

В основном, если кто-то должен записать:

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

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

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

два:

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

interface MyInterface {
  void methodA();
}

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

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

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

Я полагаю что:

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 брошен, когда время выполнения пробует к derefence myShape. Этот код сообщает о скрытой форме, когда он должен сообщать о нулевом указателе.

Или сделайте свое собственное исключение или найдите соответственно специализированное исключение в API. Это не, как будто расширение Исключения или RuntimeException тягостно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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