Как RuntimeExceptions не проверяется компилятором, даже если они расширяют класс Exception?

Когда мы создаем CustomException путем расширения класса Exception, оно проверяется компилятором, но даже несмотря на то, что RuntimeExceptions расширяет класс Exception, они не проверяются компилятором.

Как это устанавливается в компиляторе. Я нашел раздел в JLS, в котором говорится Зачем.

Почему исключения времени выполнения не проверяются
Классы исключений времени выполнения (RuntimeException и его подклассы) освобождаются от проверки во время компиляции, потому что, по мнению разработчиков языка программирования Java, объявление таких исключений не принесет существенной пользы. в установлении корректности программ. Многие операции и конструкции языка программирования Java могут приводить к возникновению исключений во время выполнения. Информация, доступная компилятору, и уровень анализа, который выполняет компилятор, обычно недостаточны, чтобы установить, что такие исключения во время выполнения не могут возникнуть, даже если это может быть очевидно для программиста. Требование объявления таких классов исключений просто раздражало бы программистов.

Что-то происходит за кулисами, как в случае с маркерными интерфейсами.

Я ищу источник, который может объяснить, как это делается, а также почему нет родительского класса для всех проверенных исключений?


java exception jls exception-handling
person ManuPK    schedule 17.07.2012    source источник

Ответы (3)


arrow_upward
2
arrow_downward

Происходит ли что-то за кулисами, как в случае с маркерными интерфейсами?

Тот факт, что RuntimeException освобожден от правила, согласно которому все подклассы Exception являются проверенными исключениями, является просто частью спецификации.

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

person aioobe    schedule 17.07.2012
comment
Поскольку это проверка времени компиляции, я полагаю, что она будет зависеть от компилятора, а не от JVM. - person assylias; 17.07.2012

arrow_upward
2
arrow_downward

Компилятор проверяет все подклассы Throwable, кроме подклассов Error и RuntimeException. Он просто проверяет, является ли Throwable подклассом этих классов.

Примечание: у вас может быть подкласс Throwable, который не является ошибкой или исключением, и он будет проверен.

person Peter Lawrey    schedule 17.07.2012

arrow_upward
1
arrow_downward

В любой момент кто-то может ввести ноль в вашу программу. Если вы когда-нибудь разделите, это может привести к ошибке деления на ноль, которая выдаст RuntimeExcpetion с именем ArithmeticException.

Теперь, если бы вам нужно было включить блоки try/catch вокруг всех ваших операторов деления, код был бы загроможден обработкой ошибок, которая отвлекала бы от удобочитаемости основной цели кода, которая может быть чем угодно (но, вероятно, не об отлавливании). разделить на ноль ошибок).

У Java либо был выбор: найти баланс между удобочитаемостью и надежностью, либо обеспечить надежность во всех случаях с некоторыми «допущениями», повышающими удобочитаемость. Другими словами, когда создавался язык Java, решение сбалансировать читабельность с надежностью выглядело бы как выбор между загрязнением исходного кода, написанного пользователем, и необходимостью захвата ArithmeticExcpetion вокруг любой операции деления. Альтернатива, которая заключается в том, чтобы всегда обеспечивать надежность, но делать определенные типы Exception не подлежащими обязательному захвату, обеспечивает надежность программы без ущерба для читаемости исходного кода (за счет знания того, что язык несколько сложнее, поскольку он имеет две категории). из Exceptionс).

person Edwin Buck    schedule 17.07.2012