Сначала я приведу вам пример (но в самом конце - ответ, почему спор).
Предположим, что вы редактируете документ в редакторе документов на основе Java, и после того, как вы это сделаете, вы выбираете Файл-> Сохранить как ... и решили сохранить документ в том, на который у вас нет разрешения на запись. Редактор не вылетит на вас с уродливой трассировкой стека, он просто скажет вам, что не может сохранить файл и позволит вам продолжить редактирование и / или сохранение в другом месте.
В таком случае это, вероятно, проверенное исключение, которое ожидали, ловили и действовали, чтобы любезно восстановиться после него.
С другой стороны, нужно добавить в них деление на ноль или исключение нулевого указателя, вызванное ошибкой программирования, которая поднимает свою уродливую голову только в определенных условиях. Это может произойти где угодно в коде, ОЗУ может быть повреждено и т. Д. Ни один документ API не скажет вам, что «этот метод выкинул бы деление на ноль, если ОЗУ повреждено» .
Проверенные исключения должны быть частью дизайна, и пользователи этого API должны подготовиться к их обработке. Непроверенные исключения могут происходить почти везде и находятся вне нашего контроля.
Противоречие возникает из-за того, что программисты используют непроверенные исключения (начиная с RuntimeException), когда они должны использовать проверенные исключения:
- как ярлык, чтобы не беспокоить компилятор
- чтобы их подписи выглядели проще
- потому что они считают, что проверенные исключения являются проблемой зависимости (если вы добавляете новое проверенное исключение в реализующий класс, вы должны изменить сигнатуру интерфейса) и наоборот.