не может обрабатывать исключенные исключения java с помощью блока try / catch?

18

В учебнике я нашел , что Unchecked Exception не может обрабатываться вашим кодом , то есть мы не можем использовать try/catch block, а примеры - это исключения, такие как ArrayIndexOutOfBoundsException, NullPointerException. . Но эти исключения могут быть обрабатывается с помощью блока try / catch. Я думаю, что я не совсем понимаю концепцию!

Также я думаю, что ключевое слово throw может использоваться только с try/catch block.can throw Ключевое слово будет использоваться с UncheckedException ?

    
задан Aravindh an 12.11.2011 в 13:21
источник
  • Можете ли вы опубликовать ссылку на учебник? –  Don Roby 12.11.2011 в 13:23
  • , а затем есть Ошибки, которые похожи на исключенные исключения, за исключением того, что они не являются исключениями, и вы не должны их вообще ловить (но вы все равно можете). –  Thilo 12.11.2011 в 13:34
  • Вы даже можете выбросить Throwable и его подклассы (которые не являются ни ошибкой, ни исключением). Они обрабатываются как проверенные исключения компилятором. Все они пойманы уловом (Throwable t) –  Peter Lawrey 12.11.2011 в 14:52
  • Учебник ошибочен. Где вы это читали? Или же он не говорит об этом, он просто говорит, что компилятор не будет применять улов или броски RuntimeExceptions и Errors. –  EJP 13.11.2011 в 05:23

6 ответов

26

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

  

Unchecked Exception не может обрабатываться вашим кодом, то есть мы не можем использовать блок try / catch

Конечно, мы можем - но нам этого не нужно.

  

Также я думаю, что ключевое слово throw может использоваться только с try / catch block.can throw Keyword будет использоваться с Unchecked Exception?

Обратите внимание, что есть два :

  • throw явно выдает созданный объект исключения. throw new NullPointerException(); работает отлично, хотя явно создание этого конкретного исключения является необычным, и большинство из них считают его плохим.
  • throws заявляет, что метод может исключить это исключение. Исключая исключения, это необязательно, но может быть полезно для документирования факта (опять же, обычно не было объявлено throws NullPointerException , потому что это в значительной степени данное).
ответ дан Michael Borgwardt 12.11.2011 в 13:26
  • Почему вы говорите, что бросание новых экземпляров исключений - необычный / плохой стиль? В любом случае кому-то нужно создать исключение, не так ли? –  Pacerier 24.06.2014 в 14:26
  • @Pacerier Я говорил конкретно о NullPointerException, который обычно создается JRE, а не кодом Java. –  Michael Borgwardt 24.06.2014 в 14:52
  • Если для нашей функции требуется непустой входной сигнал, но вызывающий код отправляется с пустым вводом, было бы нецелесообразно бросать новое исключение NullPointerException (необязательно завернутое в исключение «незаконного аргумента», например исключение IllegalArgumentException)? Альтернатива, похоже, использует наши переменные, как если бы они не были нулевыми и позволяли JRE вызывать исключение NullPointerException на протяжении всей нашей функции, но это кажется неуклюжим и не устойчивым к неожиданным ошибкам. –  Pacerier 24.06.2014 в 17:45
  • @Pacerier: простой IllegalArgumentException будет правильным выбором –  Michael Borgwardt 24.06.2014 в 17:49
  • «Конечно, мы можем, но нам это не нужно». Как насчет регистрации? –  Pieter De Bie 07.10.2015 в 08:20
Показать остальные комментарии
5

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

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

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

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

try {
   ... code that can throw CheckedException ...
} catch (CheckedException oopsSomethingBadHappened) {
    throw new RuntimeException("Something bad happened!", oopsSomethingBadHappened);
}
    
ответ дан Guillaume 12.11.2011 в 13:29
  • Я чувствую, что шаблон используется для удобства разработчика, но игнорирует дополнительную работу, которую пользователи API должны делать, чтобы угадать, что имел в виду разработчик. –  Salvador Valencia 21.09.2016 в 20:43
4

Все необработанные исключения могут обрабатываться так же, как и проверенные - если вы хотите, вы можете позволить им пройти, объявив, что метод throws them:

public void m() throws RuntimeException {}

Или вы можете catch их:

public void m() {
    try {
        // some code
    } catch (RuntimeException re) {
        // do something
    }
}

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

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

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

    
ответ дан Óscar López 12.11.2011 в 13:31
2

Легкий способ подумать о различии состоит в том, чтобы думать, что проверка относится к компиляции. Если исключение является проверенным исключением, компилятор проверяет, что ваш код либо генерирует исключение, либо обрабатывает его в блоке try / catch во время компиляции. Для непроверенных исключений компилятор не будет выполнять такую ​​проверку. Вы можете обрабатывать проверенные / непроверенные исключения одинаково (с try / catch / throws), разница просто заключается в проверках, выполняемых компилятором. У этого сообщения есть достойный пример .     

ответ дан Chris 12.11.2011 в 13:30
2

В дополнение к Гийому:

  • Исключенные исключения - это, как правило, ошибки программирования, которые не должны возникать вообще, если они выполняются правильно (индекс из привязанного, нулевого указателя, класс cast, ...), и поэтому вызывающий / пользователь обычно ничего не может с ними поделать.
  • проверены исключения, потому что они были вне контроля программиста (сеть недоступна, файловая система недоступна, параллельные модификации, такие как дублированный первичный ключ, ...)
  • Обычно ошибки запускаются JVM, и обычно приложение останавливается (из памяти, переполнение стека, ...)
ответ дан Puce 12.11.2011 в 14:19
0

Да, вы можете исключить исключенные исключения из throw . И да, вы можете поймать непроверенные исключения в блоке catch .

    
ответ дан tobiasbayer 12.11.2011 в 13:26
  • Вы также можете распространять их с помощью бросков явно, что необязательно, но может сделать вещи более ясными в сигнатуре метода. –  Thilo 12.11.2011 в 13:31
  • @ Тило, Хм, бросает за непроверенные исключения? Я не могу придумать случай, когда это было бы полезно ... Обычно исключенные исключения имеют смысл НЕ быть пойманными, потому что они представляют ошибки программирования, и ваша программа ДОЛЖНА разбиться в этом случае. Говорить клиенту, что вы ожидаете выбросить их, будет смущать, на мой взгляд. В каком случае вы имеете в виду? –  Guillaume 12.11.2011 в 13:36
  • Java SDK API полон бросков IndexOutOfBoundsException и друзей. См. Download.oracle.com/javase/1.5.0/docs/api/java/lang/String.html, а также ответ @ Michael. –  Thilo 12.11.2011 в 13:39