Пожалуйста, объясните RuntimeException в Java и где его следует использовать - PullRequest
9 голосов
/ 22 августа 2010

Я слежу за этим великим обсуждением в SO под названием: Случай с проверенными исключениями , но я не могу понять, где именно следует использовать RuntimeException и чем он отличается от обычных исключений и его подклассов. Поиск в Google дал мне сложный ответ, то есть он должен использоваться для устранения ошибок логики программирования и должен генерироваться, когда обычно не должно возникать никаких исключений, например в блоке по умолчанию конструкции switch-case.

Не могли бы вы объяснить более подробно RuntimeException здесь. Спасибо.

Ответы [ 2 ]

18 голосов
/ 22 августа 2010

Я не могу понять, где именно следует использовать RuntimeException

Это, вероятно, потому что вы смотрите на аргумент , то есть люди не соглашаются именно по этому вопросу.

и чем он отличается от обычных исключений и его подклассов.

Очень просто: все подклассы Exception (кроме RuntimeException и его подклассов) проверено т.е. компилятор отклонит код, который вы перехватили, или объявит его в сигнатуре метода.Тем не менее, подклассы RuntimeException не проверены .

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

Это общепринятая точка зрения, согласно которой для всего, с чем программа может с пользой работать, вы должны использовать флажокисключения, потому что тогда компилятор заставит вас разобраться с ними.И наоборот, программы, как правило, бесполезно работают с ошибками программиста, поэтому их не нужно проверять.Вот как Java Standard API использует RuntimeException.

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

Одно наблюдение, что IMO поддерживает это представление, состоит в том, чтообщепринятая мудрость «использовать непроверенные исключения только для ошибок программиста» на самом деле является в основном рационализацией обратного рассуждения: нет причины безопасности кода, почему компилятор не должен заставлять вас иметь дело с ошибками программиста.Однако что-то вроде NullPointerException и ArrayIndexOutOfBoundsException может появиться практически где угодно, и если бы они были проверены, никто бы никогда не захотел программировать на Java.Таким образом, дизайнеры языка должны были сделать исключение для них и сделать их непроверенными.Чтобы объяснить это, они придумали историю «непроверенные исключения для ошибок программиста».

17 голосов
/ 22 августа 2010

Цитаты из Effective Java 2nd Edition, Item 58: Использовать проверенные исключения для восстанавливаемых условий и исключения времени выполнения для ошибок программирования

Язык программирования Java предоставляет три вида бросаемых элементов: проверенные исключения , исключения времени выполнения и ошибки . У программистов есть некоторая путаница относительно того, когда целесообразно использовать каждый тип броска. Хотя решение не всегда четко сформулировано, существуют некоторые общие правила, которые обеспечивают четкое руководство.

Кардинальное правило при принятии решения о том, использовать ли проверенное или непроверенное исключение:

  • Используйте проверенные исключения для условий, от которых можно ожидать, что вызывающий абонент сможет восстановить . Вызывая проверенное исключение, вы заставляете вызывающего обработать исключение в предложении catch или распространять его наружу. Следовательно, каждое проверенное исключение, которое метод объявлен для выброса, является мощным указанием пользователю API, что связанное условие является возможным результатом вызова метода.
  • Использовать исключения времени выполнения для индикации ошибок программирования . Подавляющее большинство исключений времени выполнения указывают нарушения предусловий . Нарушение предусловия - это просто отказ клиента API от соблюдения контракта, указанного в спецификации API.

Вот пример:

  • При попытке прочитать файл с произвольным именем файл может не существовать. Это не строго программная ошибка, когда файл не существует (например, возможно, он существовал раньше, но затем был случайно удален). Клиенты могут захотеть восстановиться после этого. Таким образом, FileNotFoundException является проверенным исключением.
  • Если вы даете null строку как имя файла, а затем NullPointerException (или, возможно, IllegalArgumentException - еще один спорный дебаты) должны быть выброшены. Клиент API должен предоставить допустимое строковое значение; null нет. Что касается API, то это ошибка программиста, которую легко предотвратить. Оба эти исключения являются исключениями времени выполнения.

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

Проверенные исключения являются замечательной особенностью языка программирования Java. В отличие от кодов возврата, они заставляют программиста справляться с исключительными условиями, значительно повышая надежность. Тем не менее, чрезмерное использование проверенных исключений может сделать API гораздо менее приятным в использовании. Если метод выбрасывает одно или несколько проверенных исключений, код, который вызывает метод, должен обрабатывать исключения в одном или нескольких блоках catch или должен объявить, что он throws исключений, и позволить им распространяться наружу. В любом случае, это накладывает нетривиальную нагрузку на программиста.

Бремя оправдано, если:

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

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

Итак, вот краткое изложение рекомендации Effective Java 2nd Edition :

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

Смотри также

  • Effective Java 2nd Edition
    • Элемент 58: Использовать проверенные исключения для восстанавливаемых условий и исключения времени выполнения для ошибок программирования
    • Пункт 59: Избегать ненужного использования проверенных исключений
    • Пункт 60: Поддерживать использование стандартных исключений
    • Item 61: Бросить исключения, соответствующие абстракции
    • Элемент 62: Документировать все исключения, создаваемые каждым методом

Техническое определение

Исключение unchecked определяется как RuntimeException и его подклассы, и Error и его подклассы. Они не должны быть объявлены в предложении throws метода.

Ссылки

Похожие вопросы

...