Ответ 1

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

Непроверенные исключения - противоречие гласит:

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

Наиболее распространенным источником ClassNotFoundException является код типа

classLoader.loadClass(className);

что рефлексивно загружает класс на основе имени, найденного в файле конфигурации, сериализованном вводе или удаленном вызове процедуры.

Это отличается от ClassNotFoundError, который чаще всего возникает из программы статически, скомпилированной с другими классами, которые не могут быть найдены компоновщиком JVM во время выполнения.

Что отличает рефлексивный случай использования (проверен) от отказа связать статически скомпилированный код (ошибка времени выполнения)?

Контекст

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

Static: Caller просто пытается использовать класс, доступный во время компиляции. Контекст не доступен.

Восстановление

Отражающий: вызывающий может выполнить переход к другой реализации или попробовать стратегию по умолчанию.

Static: язык Java явно не поддерживает замену разных точек ссылки.

перефразируя

Отражающий: вызывающий должен часто преобразовывать ошибку в другой тип, например, a IOException при неудаче десериализации.

Static: Если часть вашей программы отсутствует, вы не можете полагаться на нужную часть вашей программы, чтобы объяснить, почему одна часть отсутствует в других частях.

Ответ 2

A ClassNotFoundException вызывается, когда ваш код вызывает Class.forName() в имени класса, который не может быть разрешен классу на пути к классу приложения (свободно говоря). Это может быть имя с ошибкой, указанное пользователем приложения, и, следовательно, есть потенциальная причина сообщать об этом пользователю и, возможно, даже повторить попытку с исправленным именем класса. Другими словами, это может быть восстановимой ошибкой... в некоторых случаях... поэтому вы можете утверждать, что решение сделать это проверено.

В любом случае:

• "правильность" любого выбора между проверенным и неконтролируемым - это мнение материи, а не объективный факт,
• в прошлом разработчики Java сделали неправильный выбор в некоторых случаях, и
• после того, как выбор сделан, нет возврата... без нарушения обратной совместимости.

В отличие от этого, если у вас возникла проблема во время процесса загрузки/инициализации класса, вы, скорее всего, получите NoClassDefFoundError. Это определенно не восстанавливается. Когда это происходит, у вас есть один или несколько классов в состоянии, где они существуют в JVM, но не могут быть инициализированы или созданы. (Вы также увидите NoClassDefFoundError, если JVM не сможет найти ваш назначенный класс точки входа. Но если это произойдет, ваше приложение даже не получит шанс попытаться восстановить...)

Ответ 3

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

И насколько я знаю, понятие проверенных исключений существует только в Java.

Вопрос: может ли программа восстановиться после исключения ClassNotFoundException?

Это больше всего бросается методом Class.forName. Это зависит от вашей программы, поэтому концепция проверенных и непроверенных является немного случайной, потому что как разработчик API должен знать, сможет ли моя программа восстановиться или нет. Когда мне нужен класс во время выполнения, и я не могу его обработать, это было бы неконтролируемым для меня, однако, когда я спрашиваю у пользователя что-то и загружаю класс на основе этого, возможно, ввод просто неправильный, и я могу попросить у него что-то еще. Но большую часть времени я бы сказал, что вы не можете оправиться от него, и было бы лучше, если бы он был непроверенным.

Однако, на мой взгляд, проверенные исключения используются api и третьими сторонами, чтобы напомнить программисту, что эта проблема может возникнуть, и о необходимости подумать об этом. И так как загрузка чего-либо, основанного на чистой String, может завершиться неудачей и несовместима со всей статической типизированной концепцией языка Java, исключение помечено как проверенное, поэтому вам напоминают, что вы уничтожаете свою статическую безопасность. Однако это только мое мнение.

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