Rest Dao 设计与异常处理答案

【问题标题】：Rest Dao design and exception handlingRest Dao 设计与异常处理
【发布时间】：2011-08-19 21:41:53
【问题描述】：

我必须设计一个调用 REST WS 的 DAO。此 WS 必须从给定的用户名和密码返回用户凭据。

案例 1：找到用户 => REST WS 发送 http 代码 200 和凭据响应。

案例 2：未找到用户 => REST WS 发送 http 代码 400 和带有原因的错误对象。

案例 3：找到了用户，但他的帐户已被禁用 => REST WS 发送 http 代码 400 和带有原因的错误对象。

案例 4：REST WS 不可用

在我的 DAO 中映射 REST WS 响应的最佳方式是什么？

1 - 我在我的 DAO 中抛出功能检查异常以处理错误对象情况，并在正常情况下返回凭据响应对象。当 REST WS 不可用时，我会抛出未经检查的异常

2 - 我不会在我的 DAO 中抛出任何功能异常，因为这是服务层的工作。我返回 REST WS 返回的内容，例如，包装对象中的凭据响应和错误响应，我让服务层检查这些对象以完成正确的工作。当 REST WS 不可用时，我会抛出未经检查的异常

3 - 我只为错误情况抛出未经检查的异常，我让服务层决定如何处理它。我只返回凭据响应。

非常感谢您。

【问题讨论】：

标签： java rest exception-handling dao

【解决方案1】：

我更喜欢选项 1，因为您的 DAO 负责了解远程数据源返回的内容。您的服务层位于您的 DAO 之上，不需要了解远程源的任何复杂性；这包括如何通过网络返回错误。

【讨论】：

好的，谢谢，对于选中与未选中的选择？为什么是 1 而不是 3？
我的个人偏好总是在服务层可以做一些有价值的事情时抛出检查。这迫使服务层开发人员实际考虑找不到用户时会发生什么等？ 99% 的情况下，某些业务规则将规定某些特殊逻辑应该发生。根据我的经验，对“未找到”类型条件进行未经检查的处理通常只会在运行时出现在 NPE 中。我真的很喜欢编译时检查。

【解决方案2】：

HTTP 协议中的 4XX 响应被定义为客户端错误，我认为确实有资格在 DAO 层中引发异常。错误对象只是抛出异常的一种表示。

如果您应该抛出已检查或未检查的异常，可能需要进行长时间的讨论，最终取决于个人偏好或项目中的一般编码指南。通过抛出异常，您可以将异常类型映射到相应的 HTTP 错误代码，例如BadCredentialsException 变成 HTTP 错误 400 任何无法映射的东西都会变成 500 内部服务器错误

【讨论】：