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

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

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

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

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

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

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

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

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

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

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

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

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

Вот пример:

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

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

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

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

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

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

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

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

Смотрите также

• Effective Java 2nd Edition
  • Item 58: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors
  • Правило 59: Избегайте ненужного использования отмеченных исключений
  • Правило 60: Поддерживайте использование стандартных исключений
  • Правило 61: создавайте исключения, соответствующие абстракции
  • Правило 62: Задокументируйте все исключения, создаваемые каждым методом

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

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

использованная литература

• JLS 11.2 Проверка исключений во время компиляции

Связанные вопросы

• Когда в Java следует создавать проверенное исключение, а когда - исключение времени выполнения?
• Когда выбирать отмеченные и непроверенные исключения
• Дело против проверенных исключений
• IllegalArgumentException или NullPointerException для параметра null?