Tag: service layer

服务层中的已检查与未检查的例外

我处理具有遗留服务层的项目，如果请求的记录不存在，则在许多地方返回null，或者由于呼叫者未被授权而无法访问。 我在谈论ID要求的特定记录。 例如，类似于： UserService.get(userId); 我最近推动改变这个API，或者补充一个抛出exception的新API。 关于已检查与未经检查的例外的争论随之而来。 从JPA / Hibernate等人的设计者那里得到一个注释，我建议未经检查的exception可能是最合适的。 我的论点是，无法合理地期望API的用户从这些exception中恢复，并且在99％的情况下，我们最多只能通知应用程序用户发生了一些错误。 将运行时exception传播到通用处理机制显然会减少处理边缘情况exception所涉及的大量复杂性和所需的分支处理。 但是，围绕这种方法存在很多问题（这是正确的）。 为什么选择JPA / EJB和Hibernate等项目的设计者使用未经检查的exception模型？ 它有充分的理由吗？ 有什么利弊。 使用这些框架的开发人员是否仍然可以使用适配器包装器之类的东西处理接近抛出它们的运行时exception？ 我希望这些问题的答案可以帮助我们对自己的服务层做出“正确”的决定。