Когда следует использовать Throwable вместо нового исключения?

Учитывая: Throwable – суперclass Throwable Exception .

Когда я читаю тексты о написании собственных «исключений», я вижу примеры использования Throwable в блоке catch а в других текстах показано, что в блоке catch используется new Exception() . Я еще не видел объяснений, когда нужно использовать каждый.

Мой вопрос в том, когда следует использовать Throwable и когда следует использовать new Exception() ?

Внутри блока catch или else используется:

 throw throwable; 

или

 throw new Exception(); 

(из комментариев) Проблема, связанная с этим, заключается в том, что мне нужно передать «исключение» в кусок кода, который создает коллега, если сбор не создается.

В этом случае вам может потребоваться выбросить проверенное исключение . Вы можете создать Exception , соответствующий существующий подclass (исключая RuntimeException и его подclassы, которые не отмечены) или пользовательский подclass Exception (например, « CollectionBuildException »). См. Учебник по исключениям в Java, чтобы ускориться с исключениями Java.

Всегда бросайте Exception (никогда не Throwable ). Вы вообще не поймаете Throwable , но можете. Throwable – это суперclass для Exception и Error , поэтому вы можете поймать Throwable если хотите не только перехватывать Exception s, но и Error s, это то, что нужно. Дело в том, что Error – это, как правило, то, что нормальное приложение не будет и не должно улавливать, поэтому просто используйте Exception если у вас нет конкретной причины использовать Throwable .

Вы не должны действительно ловить исключение и бросать новый как общий, как «новое исключение».

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

 try { // Do some stuff here } catch (DivideByZeroException e) { System.out.println("Can't divide by Zero!"); } catch (IndexOutOfRangeException e) { // catch the exception System.out.println("No matching element found."); } catch (Throwable e) { throw e; // rethrow the exception/error that occurred } 

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

Только в двух местах вы должны увидеть слово Throwable в коде:

 public static void main(String args[]) { try { // Do some stuff } catch(Throwable t) { } } 

А ТАКЖЕ

 public class SomeServlet extends HttpServlet { public void doPost(HttpRequest request, HttpResponse response) { try { // Do some stuff } catch (Throwable t) { // Log } } } 

Throwable – это интерфейс, а не class. Два classа расширяют Throwable, Exception и Error.

Правило: быть как можно более конкретным, если вы ловите исключения – это означает, например, ловлю Исключение вместо Throwable и исключение IOException вместо Exception.

Не поймайте Ошибки – ошибки – это ошибки. Исправьте код.

Если вам нужно поймать абсолютно все, используйте «catch Throwable», но это плохая форма.

throw new Exception(); это то, что вы никогда не должны делать в блоке catch, но вам может понадобиться или вы хотите сделать new SomeException(throwable); (сохраняя полную трассировку стека) вместо throw throwable; чтобы соответствовать API вашего метода, например, когда он объявляет о SomeException но вы вызываете код, который может генерировать IOException которое вы не хотите добавлять в предложение throws метода.

Вероятно, наиболее распространенным случаем является new RuntimeException(throwable); чтобы вообще не иметь throws . Многие люди скажут вам, что это ужасное злоупотребление, потому что вы должны использовать проверенные исключения. IMO они ошибаются и проверенные исключения являются ошибкой в ​​дизайне языка Java, что приводит к уродливому, не поддающемуся контролю коду.

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

Так что просто поймите Exception (или, еще лучше, более мелкозернистого исключения).

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

Все исключения являются проблемой в конце … тоже говорят Ошибки – это ничего не значит.

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

Как правило, вы не бросаете или не бросаете Throwable. В частности, ошибки JVM (которые расширяют Error ()) не предназначены для захвата кода пользователя, если вы не выполняете странную работу на системном уровне.

Обращайтесь с «Throwable» как с артефактом языка. Класс «Исключение» назван так, потому что это тот, который предназначен для использования программистами, когда они хотят, чтобы кодовый блок вышел «исключительно» – не выходил нормально или не возвращал значение.

Это включает в себя как регулярные ситуации с ошибками (по «регулярному», я имею в виду, в отличие от ошибок JVM), и места, где вы используете исключения в качестве механизма управления.

Вы не должны использовать Исключения как «тип возврата» либо …

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

Я видел случаи, когда тесные циклы, которые бросали исключения как «отрицательные», например, для распределения идентификаторов, эта процедура занимала около 99% процессорного времени .. при замене вместо документированной константы возврата это уменьшалось до 25%.

  • IllegalArgumentException или NullPointerException для нулевого параметра?
  • исключения try-catch в Swift
  • Java List.add () UnsupportedOperationException
  • C ++ - аргументы для исключений по возвратным кодам
  • Неподтвержденное исключение Java
  • Будут ли исключения C ++ безопасно распространяться через C-код?
  • Почему загрузка формы не может устранить исключение?
  • Как реализована среда выполнения обработки исключений C ++?
  • try / catch с InputMismatchException создает бесконечный цикл
  • Как я могу обнаружить, когда исключение было выбрано глобально в Java?
  • Java: проверено на исключение исключения исключений
  • Давайте будем гением компьютера.