Trabajo en un proyecto con una capa de servicio heredada que devuelve nulo en muchos lugares si no existe un registro solicitado o no se puede acceder debido a que la persona que llama no está autorizada. Estoy hablando de registros específicos solicitados por ID. Por ejemplo, algo como:

UserService.get(userId);

He presionado recientemente para que se cambie esta API, o se complemente con una nueva API que arroje excepciones en su lugar. El debate sobre las excepciones marcadas frente a las no marcadas ha tenido lugar.

Tomando una nota de los diseñadores de JPA / Hibernate et all., He sugerido que las excepciones no marcadas pueden ser las más apropiadas. Mi argumento es que no se puede esperar razonablemente que los usuarios de la API se recuperen de estas excepciones y, en el 99% de los casos, en el mejor de los casos podemos notificar al usuario de la aplicación que se ha producido algún error.

Tener excepciones de tiempo de ejecución propagadas hasta mecanismos de manejo genéricos obviamente reducirá gran parte de la complejidad y el manejo de sucursales requerido para tratar las excepciones de casos extremos. Pero, existe una gran preocupación en torno a este enfoque (con razón).

¿Por qué los diseñadores de proyectos como JPA / EJB e Hibernate han seleccionado un modelo de excepción no verificado? ¿Hay una muy buena justificación para ello? ¿Cuáles son los pros / contras? ¿Deberían los desarrolladores que usan estos marcos aún manejar las excepciones de tiempo de ejecución cerca de donde se arrojan con algo así como envoltorios de adaptadores?

Espero que las respuestas a estas preguntas nos ayuden a tomar la decisión "correcta" con respecto a nuestra propia capa de servicio.