Пожалуйста, объясните RuntimeException в Java и где его следует использовать
Я слежу за этим великим обсуждением в SO под названием: Дело против проверенного исключения , но я не могу понять, где именно следует использовать RuntimeException и чем он отличается от обычных исключений и их подклассов. Поиск в Google дал мне сложный ответ, то есть он должен использоваться для устранения ошибок логики программирования и должен генерироваться, когда обычно не должно возникать никаких исключений, например в блоке по умолчанию конструкции switch-case.
Пожалуйста, объясните RuntimeException более подробно здесь. Спасибо.
2 ответа
Я не могу проследить где именно Следует использовать RuntimeException
Вероятно, это потому, что вы смотрите на аргумент , т.е.люди расходятся во мнениях именно по этому поводу.
и чем это отличается от нормального Исключения и их подклассы.
Очень просто:Все подклассы Exception (кроме RuntimeException и его подклассов) проверены , то есть компилятор отклонит код, если вы не поймаете или не объявите их в сигнатуре метода. Однако подклассы RuntimeException не отмечены .
Поиск в Google дал мне сложный ответ: то есть его следует использовать для решения с ошибками логики программирования и должен быть выброшен, когда нет исключения обычно должно происходить, например, в блок переключателя по умолчанию построить.
Это общепринятая мудрость, которая гласит, что для всего, с чем программа может с пользой справиться, вы должны использовать проверенные исключения, потому что тогда компилятор заставит вас иметь дело с ними. И наоборот, программы обычно бесполезны для исправления ошибок программиста, поэтому их не нужно проверять. Вот как стандартный API Java использует RuntimeException .
Обсуждение, на которое вы ссылаетесь, вызвано мнением некоторых людей (включая меня), которые думают, что проверенные исключения приводят к плохому коду и поэтому не должны использоваться. Поскольку вы не можете отключить проверку исключений в компиляторе, единственный способ сделать это - использовать только RuntimeException и его подклассы.
Одно наблюдение, которое ИМО поддерживает эту точку зрения, заключается в том, что общепринятая мудрость «использовать непроверенные исключения только для ошибки программиста» на самом деле в основном является рационализацией обратных рассуждений: нет причины безопасности кода, по которой компилятор не должен заставлять вас разбираться с ошибками программиста.Однако что-то вроде NullPointerException и ArrayIndexOutOfBoundsException может возникнуть практически где угодно, и если бы они были проверены, никто бы никогда не захотел программировать на Java. Таким образом, разработчикам языка пришлось сделать для них исключение и сделать их не отмеченными. Чтобы объяснить это, они придумали историю «непроверенные исключения - ошибки программистов».
Цитаты из Эффективное 2-е издание Java, пункт 58: Используйте проверенные исключения для восстанавливаемых условий и исключения времени выполнения для ошибок программирования
В языке программирования Java есть три типа метательных объектов : проверены исключения , исключения времени выполнения и ошибки . Среди программистов существует некоторая путаница относительно того, когда уместно использовать каждый вид метательных объектов. Хотя решение не всегда однозначно, существуют некоторые общие правила, которые могут служить надежным ориентиром.
Кардинальное правило при принятии решения о том, использовать ли проверенное исключение или непроверенное, следующее:
- Используйте проверенные исключения для условий, из которых вызывающий может разумно ожидать восстановления . Выбрасывая проверенное исключение, вы заставляете вызывающую сторону обработать исключение в предложении
catchили распространить его наружу. Каждое проверенное исключение, которое, как объявлено, генерирует метод, является мощным указанием для пользователя API, что связанное условие является возможным результатом вызова метода.- Используйте исключения времени выполнения для обозначения ошибок программирования . Подавляющее большинство исключений времени выполнения указывают нарушения предварительного условия . Нарушение предусловия - это просто несоблюдение клиентом API условий контракта, указанного в спецификации API.
Вот пример:
- При попытке прочитать файл с произвольным именем файл может не существовать. Это не совсем ошибка программирования, когда файл не существует (например,возможно, это было раньше, но потом было случайно удалено). Клиенты могут захотеть оправиться от этого. Таким образом,
FileNotFoundExceptionявляется проверенным исключением. - Если вы укажете строку
nullв качестве имени файла, тогда следует вызватьNullPointerException(или, возможно, исключениеIllegalArgumentException- еще одно спорное обсуждение). Клиент API должен предоставить допустимое строковое значение;null- нет. Что касается API, то это ошибка программиста, которую легко предотвратить. Оба эти исключения являются исключениями времени выполнения.
Правило 59: Избегайте ненужного использования отмеченных исключений также предоставляет дополнительные рекомендации:
Проверенные исключения - замечательная функция языка программирования Java. В отличие от кодов возврата, они заставляют программиста работать в исключительных условиях, значительно повышая надежность. Тем не менее, чрезмерное использование проверенных исключений может сделать использование API гораздо менее приятным. Если метод генерирует одно или несколько проверенных исключений, код, который вызывает этот метод, должен обрабатывать исключения в одном или нескольких блоках
catchили должен объявить, что онвыбрасываетисключения и позволяет они распространяются наружу. В любом случае это накладывает на программиста нетривиальную ношу.Бремя оправдано, если:
- исключительное состояние не может быть предотвращено правильным использованием API, и
- программист, использующий API, может предпринять некоторые полезные действия, столкнувшись с исключением.
Если оба этих условия не выполняются, неконтролируемое исключение более уместно.
Итак, вот краткое изложение рекомендации из Эффективное 2-е издание Java :
- Предотвращаемые исключения, возникающие из-за ошибок пользователя API, должны быть сняты .
- Исключения, которые невозможно обработать разумным образом, также следует не отмечать .
- В противном случае исключение должно быть проверено .
См. Также
- Эффективное 2-е издание Java
- Правило 58: Используйте проверенные исключения для восстанавливаемых условий и исключения времени выполнения для ошибок программирования
- Правило 59: Избегайте ненужного использования отмеченных исключений
- Правило 60: Поддерживайте использование стандартных исключений
- Пункт 61: Выбрасывать исключения, соответствующие абстракции
- Пункт 62: Задокументировать все исключения, создаваемые каждым методом
Техническое определение
Непроверенное исключение определяется как RuntimeException и его подклассы, и Error и его подклассы. Их не нужно объявлять в предложении метода throws .