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

Exception Handling in a Java Web Application

提问by craftsman

I am developing a medium size Java Web Application with Struts as MVC framework and simple JDBC at Data Access Layer. I have been searching for exception handling best practices in such an application. I have found several articles, some of them being contradictory, only making me more confused rather than making things clear and simple. Some say it is better to reuse existing exceptions instead of defining application specific exceptions, others present a huge hierarchy of application specific exceptions for every minor trouble that may occur in the system. Some say it is better not to handle exceptions at Data Access Layer and delegate them to the Service Layer, others say Data Access Layer exceptions should be caught locally since delegating them to Service Layer would violate the abstraction between the two layers. And so on.

我正在使用 Struts 作为 MVC 框架和数据访问层的简单 JDBC 开发一个中型 Java Web 应用程序。我一直在寻找此类应用程序中的异常处理最佳实践。找了几篇文章，有些是自相矛盾的，只会让我更困惑，而不是让事情变得清晰和简单。有人说最好重用现有的异常而不是定义特定于应用程序的异常，其他人则为系统中可能发生的每个小故障提供了一个巨大的应用程序特定异常层次结构。有人说最好不要在数据访问层处理异常并将它们委托给服务层，也有人说数据访问层异常应该在本地捕获，因为将它们委托给服务层会违反两层之间的抽象。等等。

I would highly appreciate if you let me know of links/names to articles/books that present solid solutions which have worked for you in such a scenario. The solution should clear at least the following points with justifications:

如果您让我知道文章/书籍的链接/名称，这些文章/书籍提供了在这种情况下对您有用的可靠解决方案，我将不胜感激。解决方案应至少明确以下几点并提供理由：

1. Where the SQLExceptions be caught?
2. Where exceptions should be logged?
3. Should unchecked exceptions be logged?
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?
6. How should a global exception handler page be used?
7. How should struts ActionErrors be used in this context?

1. SQLExceptions 在哪里被捕获？
2. 应该在哪里记录异常？
3. 是否应该记录未经检查的异常？
4. 是否应该在表示层捕获未经检查的异常，并且应该将它们显示给用户？
5. 如何处理已检查的异常，向用户显示哪些异常以及如何处理？
6. 应该如何使用全局异常处理程序页面？
7. 在这种情况下应该如何使用 struts ActionErrors？

Thanks

谢谢

采纳答案by BalusC

1: Where the SQLExceptions be caught?

1：在哪里捕获 SQLExceptions？

In DAO classes in data access layer. You can if necessary wrap it with a custom DAO exception. This DAO exception in turn needs to be handled further as checked exception.

在数据访问层的 DAO 类中。如有必要，您可以使用自定义 DAO 异常包装它。这个 DAO 异常又需要作为检查异常进一步处理。

2: Where exceptions should be logged?

2：应该在哪里记录异常？

At the moment when you're about to throwthem or to pass through the messaging framework.

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

3: Should unchecked exceptions be logged?

3：是否应该记录未经检查的异常？

They should certainly be logged. They should namely notoccur in real world, because those are sign of a fault in the code logic (i.e. developer fault) which needs to be bugfixed asap. They should be thrown all the way up to the container and let the container handle them with an <error-page>in web.xml. To log (and eventually mail) them, use a Filterwhich listens on the error page.

他们当然应该被记录。他们应该即不发生在现实世界中，因为这些代码逻辑（即开发商故障）出现故障需要被尽快bugfixed的迹象。它们应该一直被扔到容器中，让容器用<error-page>in处理它们web.xml。要记录（并最终邮寄）它们，请使用Filter在错误页面上侦听的 。

4: Should unchecked exceptions be caught at presentation layer, and should they be shown to the user?

4：非检查异常是否应该在表现层捕获，是否应该显示给用户？

They should not occur at all.

它们根本不应该发生。

5: How checked exceptions be handled, which of them to be shown to the user and how?

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

If they are result of errorneous user input (e.g. not a number, bad email, constraint violation, etc), show them in the same form to the user. Otherwise (e.g. DB down, DAO exception and so on) either throw it all the way up to the error page, or display the error with a message to try again later.

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

6: How should a global exception handler page be used?

6：全局异常处理页面应该如何使用？

At least in an user-friendly manner. Thus, in the same layout, with some introductory "sorry" and if necessary with some error details and an email address so that the user can contact for the case that.

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

7: How should struts ActionErrors be used in this context?

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

Show them in same form to the user.

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

回答by Brian Agnew

If you can't recover from an exception, then you should let it flow out of your code (often by making it unchecked, or wrapping it in an unchecked exception). If they remain checked, you have to cater for them at each level of your code, and consequently at every abstraction layer. SQLExceptionswould normally fall into this category (you'll have to wrap them since they're checked).

如果您无法从异常中恢复，那么您应该让它从您的代码中流出（通常通过使其不受检查，或将其包装在未经检查的异常中）。如果它们仍然处于检查状态，您必须在代码的每个级别以及因此在每个抽象层中满足它们。SQLExceptions通常会属于这一类（因为它们已被检查，所以您必须将它们包装起来）。

For these exceptions, I normally log at the highest level, but present a page to the users simply detailing that somethinghas gone wrong. Normally my users aren't interested in stack traces. But I usually offer them a page to let them describe what they were doing at the time, and the logged exception ties back to this submission via a unique id (recorded in the form and in the log file with the exception). That allows me to tie back users' actions to the resulting exception.

对于这些例外，我正常登录的最高水平，但呈现页面的用户只需详细说明了事情出了问题。通常我的用户对堆栈跟踪不感兴趣。但是我通常会为他们提供一个页面，让他们描述他们当时在做什么，并且记录的异常通过唯一的 id（记录在表单和日志文件中的异常）与此提交相关联。这允许我将用户的操作与产生的异常联系起来。

The above assumes that you can't recover from SQLExceptions, and if the database is down, then you can't do something meaningful. There are exceptions to this, of course. You may find that you're talking to multiple systems, and one being down doesn't mean you can't continue in some fashion (e.g. the Amazon home page reportedly relies on 100 services, and needs to run regardless of some of these being down).

上面假设你不能从 中恢复SQLExceptions，如果数据库宕机了，那么你就不能做一些有意义的事情。当然，也有例外。您可能会发现您正在与多个系统对话，一个系统宕机并不意味着您不能以某种方式继续（例如，据报道亚马逊主页依赖于 100 项服务，并且需要运行，而不管其中的一些是否存在）向下）。

I would expect declaredexceptions to be at the same level of abstraction as the interface/methods defining them. e.g. a TradeStorewould be declared to throw a TradeException, not a SQLException(since methods of storing a trade are an implementation of TradeStore- you could store in a relational db, a JavaSpace etc.).

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

回答by Nerdfest

As a warning, when displaying lower level error messages to users, make sure they're sanitized of system information. This is an area where many security exploits originate. Log them with full information, but only display a more general error message to the user.

作为警告，当向用户显示较低级别的错误消息时，请确保他们已清除系统信息。这是许多安全漏洞的起源区域。用完整的信息记录它们，但只向用户显示更一般的错误消息。