我正在开发一个中等规模的 Java Web 应用程序，它使用 Struts 作为 MVC 框架并在数据访问层使用简单的 JDBC。我一直在寻找此类应用程序中的异常处理最佳实践。找了好几篇文章，有些是自相矛盾的，只是让我更加困惑，而不是让事情变得清晰和简单。有人说最好重用现有的异常而不是定义特定于应用程序的异常，其他人则为系统中可能发生的每个小问题提供一个巨大的应用程序特定异常层次结构。有人说最好不要在数据访问层处理异常并将它们委托(delegate)给服务层，另一些人说数据访问层异常应该在本地捕获，因为将它们委托(delegate)给服务层会违反两层之间的抽象。以此类推。
如果您让我知道文章/书籍的链接/名称，我将不胜感激，这些文章/书籍提供了在这种情况下对您有用的可靠解决方案。解决方案至少应明确以下几点并说明理由:
- 在哪里捕获 SQLExceptions？
- 应在哪里记录异常？
- 是否应记录未经检查的异常？
- 是否应在表示层捕获未经检查的异常，是否应将它们显示给用户？
- 如何处理已检查的异常，向用户显示哪些异常以及如何处理？
- 应该如何使用全局异常处理页面？
- 在这种情况下应该如何使用struts ActionErrors？
谢谢
最佳答案
1: Where the SQLExceptions be caught?
在数据访问层的 DAO 类中。如有必要，您可以使用自定义 DAO 异常对其进行包装。反过来，这个 DAO 异常需要作为检查异常进一步处理。
2: Where exceptions should be logged?
当你即将到 throw 的那一刻它们或通过消息传递框架。
3: Should unchecked exceptions be logged?
他们当然应该被记录下来。它们应该不在现实世界中发生，因为这些是代码逻辑错误(即开发人员错误)的迹象，需要尽快修复错误。它们应该一直扔到容器上，让容器用 <error-page> 处理它们。在 web.xml .要记录(并最终邮寄)它们，请使用 Filter它在错误页面上监听。
4: Should unchecked exceptions be caught at presentation layer, and should they be shown to the user?
它们根本不应该发生。
5: How checked exceptions be handled, which of them to be shown to the user and how?
如果它们是用户输入错误的结果(例如，不是数字、错误的电子邮件、违反约束等)，请以相同的形式向用户显示它们。否则(例如 DB 关闭、DAO 异常等)要么将其一直抛出到错误页面，要么显示错误并显示一条消息以稍后重试。
6: How should a global exception handler page be used?
至少以用户友好的方式。因此，在相同的布局中，带有一些介绍性的“对不起”，必要时带有一些错误详细信息和电子邮件地址，以便用户可以联系以解决该问题。
7: How should struts ActionErrors be used in this context?
以相同的形式向用户显示它们。
关于java - Java Web 应用程序中的异常处理，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2169339/