Trabalho em um projeto com uma camada de serviço herdada que retorna nula em muitos lugares se um registro solicitado não existir ou não puder ser acessado devido ao fato de o chamador não estar autorizado. Estou falando de registros específicos solicitados pelo ID. Por exemplo, algo como:

UserService.get(userId);

Fui pressionado recentemente para que essa API fosse alterada ou complementada com uma nova API que lança exceções. O debate sobre as exceções verificadas e não verificadas se segui

Tomando uma nota dos designers do JPA / Hibernate et all., Sugeri que exceções não verificadas podem ser mais apropriadas. Meu argumento é que não é de esperar que os usuários da API se recuperem dessas exceções e, em 99% dos casos, podemos, na melhor das hipóteses, notificar o usuário do aplicativo de que ocorreu algum err

Ter as exceções de tempo de execução propagadas para mecanismos de manipulação genéricos obviamente reduzirá muita complexidade e manipulação de ramificações necessária envolvida no tratamento de exceções de casos extremos. Mas há muita preocupação em torno dessa abordagem (com razão).

Por que os designers de projetos como JPA / EJB e Hibernate selecionaram o modelo de exceção não verificado? Existe uma justificativa muito boa para isso? Quais são os prós / contras. Os desenvolvedores que usam essas estruturas ainda devem lidar com as exceções de tempo de execução próximas de onde são lançadas com algo como invólucros do adaptador?

Espero que as respostas para essas perguntas possam nos ajudar a tomar a decisão "correta" em relação à nossa própria camada de serviç