Java Web 应用程序中的异常处理

1： 在哪里捕获 SQLExceptions？

在数据访问层的 DAO 类中。如有必要，可以使用自定义 DAO 异常将其包装。反过来，此 DAO 异常需要作为已检查异常进一步处理。

2：应在哪里记录异常？

在你即将通过消息传递框架的那一刻。throw

3：是否应记录未选中的异常？

它们当然应该被记录下来。它们不应该在现实世界中发生，因为这些是代码逻辑中错误（即开发人员错误）的迹象，需要尽快修复错误。它们应该一直扔到容器上，让容器用 in 来处理它们。要记录（并最终邮寄）它们，请使用错误页面上的 listens。<error-page>web.xmlFilter

4：是否应在表示层捕获未选中的异常，是否应向用户显示这些异常？

它们根本不应该发生。

5：如何处理已检查的异常，向用户显示哪些异常以及如何显示？

如果它们是用户输入错误的结果（例如，不是数字，错误的电子邮件，约束违规等），请以相同的形式向用户显示它们。否则（例如.DB关闭，DAO异常等）要么将其一直抛到错误页面，要么显示错误并显示一条消息，以便以后重试。

6：应如何使用全局异常处理程序页？

至少以用户友好的方式。因此，在相同的布局中，带有一些介绍性的“对不起”，并在必要时提供一些错误详细信息和电子邮件地址，以便用户可以联系该案例。

7： 在这种情况下，应该如何使用 struts ActionErrors？

以相同的形式向用户显示它们。

如果无法从异常中恢复，则应让它从代码中流出（通常是通过使其未选中，或将其包装在未选中的异常中）。如果它们保持检查状态，则必须在代码的每个级别以及每个抽象层满足它们的需求。 通常属于此类别（由于它们已被选中，因此必须包装它们）。SQLExceptions

对于这些异常，我通常在最高级别登录，但会向用户显示一个页面，仅详细说明出现问题。通常，我的用户对堆栈跟踪不感兴趣。但我通常会为他们提供一个页面，让他们描述他们当时在做什么，并且记录的异常通过唯一的ID（记录在表单和日志文件中，例外）与此提交相关联。这使我能够将用户的操作与生成的异常联系起来。

上述假设您无法从 中恢复，如果数据库已关闭，则无法执行有意义的操作。当然，也有例外。您可能会发现您正在与多个系统交谈，其中一个系统出现故障并不意味着您无法以某种方式继续（例如，据报道，亚马逊主页依赖于100项服务，并且需要运行，而不管其中一些服务是否关闭）。SQLExceptions

我希望声明的异常与定义它们的接口/方法处于相同的抽象级别。例如，a 将被声明为抛出一个 ，而不是 a （因为存储交易的方法是 - 你可以存储在关系数据库，JavaSpace等中）。TradeStoreTradeExceptionSQLExceptionTradeStore