отаю над проектом со старым сервисным уровнем, который во многих местах возвращает ноль, если запрошенная запись не существует или недоступна из-за того, что вызывающий абонент не авторизован. Я говорю о конкретных записях, запрошенных по ID. Например, что-то вроде:

UserService.get(userId);

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

Принимая к сведению разработчиков JPA / Hibernate и др., Я предположил, что непроверенные исключения могут быть наиболее подходящими. Мой аргумент заключается в том, что нельзя ожидать, что пользователи API оправятся от этих исключений, и в 99% случаев мы в лучшем случае можем уведомить пользователя приложения о возникновении некоторой ошибки.

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

Почему дизайнеры таких проектов, как JPA / EJB и Hibernate, выбрали модель неисключенного исключения? Есть ли для этого очень хорошее оправдание? Какие плюсы / минусы. Должны ли разработчики, использующие эти фреймворки, по-прежнему обрабатывать исключения времени выполнения, близкие к тому, где они создаются чем-то вроде оболочек адаптера?

Я надеюсь, что ответы на эти вопросы помогут нам принять «правильное» решение относительно нашего уровня обслуживания.