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

Предоставлено: Throwable - суперкласс класса Exception.

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

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

EDIT: внутри блока catch или else, используя:

throw throwable;

или

throw new Exception();

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

Ответ 3

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

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

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
}

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

Ответ 4

Только в двух местах вы должны увидеть слово 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
         }
      }
 }

Ответ 5

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

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

Не ловить ошибки - ошибки - это ошибки. Исправьте код.

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

Ответ 6

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

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

Ответ 7

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

Так просто перехватите исключение (или, еще лучше, более мелкое исключение).

Ответ 8

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

Ответ 9

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

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

Ответ 10

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

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

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

Ответ 11

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

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

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