java - DAO 模式中的异常与返回码

Question

在阅读了很多关于 Java 中异常的滥用以及您应该如何让异常在应用程序的不同层中冒泡的内容之后，我已经到了不知道我应该做什么的地步处理我的应用程序可能存在的潜在错误。

基本上，我有一个使用 DAO 模式访问数据库中数据的网络服务。所有数据库操作都可以抛出 SQLException。从今天开始，我正在使用 try catch 来捕获 SQLException，然后抛出一个名为 ExceptionDAO 的特定定义的异常，该异常将由 Web 服务处理以返回正确的消息给我的网络服务的用户(移动应用程序)。

在阅读了很多关于异常应该如何异常并且不应在控制流中使用的内容之后，我对我应该如何处理任何错误有了一个复杂的理解:

• 对任何可能发生的事情(例如用户名已经存在)使用返回码，因此，为了遵守 DAO 模式，将我的业务对象作为参数传递。我还可以使用一个特定的对来代替返回代码 + 业务对象。然后，Web 服务将使用返回代码来显示特定消息。
• 对我无法预测会发生的任何事情使用已检查的异常，让它们冒泡到网络服务来处理并向用户返回消息。 (例如，我无法预测的 SQLException:连接中止)
• 让未经检查的异常也冒泡并在这种情况下显示某种 404 错误。

我也看过 null 模式，但我认为它不太适合这种特殊情况。我还担心不要向用户提供太多信息，而是提供有用且直截了当的信息。事实上，网络服务返回的消息将由移动应用程序使用，然后向最终用户显示消息。

我希望我已经足够清楚我遇到的问题，我期待着您的回答!

Answer 1

返回码适用于C，它的特性中缺少异常处理。对于 Java，请使用异常，检查异常或运行时异常，这是个人喜好问题。

就我个人而言，我讨厌检查异常，因为它们用可能永远不会发生的边界情况信息污染了我的方法签名。但也许你想严格遵守你的类(class)契约(Contract)，即使是在这种特殊情况下也是如此。如果是这种情况，请使用已检查的异常。否则，只要检测到异常情况(例如未找到实体、实体已存在等)，就让您的方法签名保持平静并抛出运行时异常。

请注意 ExceptionDAO 不是一个好听的名字。它似乎是一个处理异常的 dao。也许像 PersistenceException 这样的东西会更好。

除了命名细节外，我认为您的方法是正确的，但并不理想。理想情况下，您不需要在从 DAO 调用方法的每个方法(或 DAO 的每个方法)中为 SQLException 执行 try/catch。相反，持久性异常转换机制 会好得多。 Spring ，例如，comes with one by default . Spring 通过代理每个 DAO 并让其代理围绕每个方法调用执行 try/catch 来实现这一点。然后，具有特定 SQL 错误代码的特定 SQLException 被转换为 Spring 自己的 DataAccessException 层次结构。因此，在上层，您最终会得到一个特定的 DataAccessException，但您不需要在每个方法中执行 try/catch。

如果您已经在使用 Spring，那么您无事可做，但如果您没有使用它并且有许多 DAO 或许多可能抛出 SQLException 和 的方法你所有的 DAO 都实现了一个接口(interface)，那么可能值得努力实现一个代理，它拦截你的 DAO 的所有方法并执行 try/catch在他们旁边。然后，在这个拦截器的 catch block 中，您将抛出 ExceptionDAO(请重命名它!)，其中包含一条消息，该消息将取决于原始 SQLException(可能还取决于其 SQL错误代码)。

这种方法的优点是您可以在程序的单个点中处理所有持久性异常。

这个非常相同的概念也可以应用于您的网络层。您可以创建一个代理来拦截每个方法调用并执行 try/catch 围绕它。然后您可以从异常中提取消息并将其发送到响应中(或您认为适合处理的任何内容)。同样，这一切都基于 Spring，这次是在 Spring MVC Exception Handling 中机制。您还可以在这里处理意外异常，即 RuntimeException 并向您的用户提供适当的消息。

同样，优势在于您可以在程序的单个点中处理到达 Web 层的所有异常。

请参阅Proxy javadocs和 this tutorial进一步引用 Java 的代理。