【问题标题】：Exception handling architecture for Java EE projectsJava EE 项目的异常处理架构
【发布时间】：2012-03-10 23:11:08
【问题描述】：

我正在尝试收集有关其他 Java EE 程序员如何处理异常的意见。您是否集中错误处理（例如 Servlet 过滤器）？

您是否为不同的应用程序层（持久性、服务等）创建不同的异常类型？

你只是吞下异常而不把它们扔到链上吗？

异常处理架构中还有哪些其他范例？你使用哪一个？为什么？

【问题讨论】：

标签： java exception jakarta-ee architecture

【解决方案1】：

例外是纯金，因为您试图找出问题所在。相应地对待他们！

吞咽异常仅在极少数情况下是可接受的，这实际上是适当的操作。

Java 中的已检查异常通常会迫使您考虑如何处理靠近实际发生位置的错误。请注意，将异常包装在 DomainException（或其适当的子类）中并将其沿调用链发送到可以实际处理并正常恢复的位置是完全可以接受的。

在大多数情况下，您有一个最顶级的 try-catch，它允许您捕获所有异常并处理它们。这就是为什么提供尽可能多的逻辑如此重要（通过将其包装在对您有意义的异常中），以便此处理程序可以相应地采取行动。

对于已知情况，然后可以采取适当的措施。

对于未知情况，这是一个非常响亮的失败问题，因为您的系统处于意外状态。尽可能多地记录——因为否则你可能无法重现它——并进入一个合适的状态（退出、拒绝进一步的服务，或者只是根据你的模型继续）。

【讨论】：

【解决方案2】：

持久层，如果它是使用 JPA 或 Hibernate 实现的，已经有它自己的异常，它们是运行时异常。

当传递非法参数时（当它们应该由表示层验证时），服务层抛出运行时异常，或者在发生可恢复错误时抛出检查异常（例如：所选名称已存在于数据库中）。

表示层的每个控制器都处理它调用的业务服务抛出的已检查异常，以提供有意义的错误消息并让用户从错误中恢复（例如：重新显示表单并要求用户选择其他名称）

来自表示层、业务层或持久层的所有其他运行时异常都由一个或多个全局异常处理程序（大多数 UI 框架支持它们）处理，它们记录异常并抛出更多或不太通用的错误消息（例如：“发生意外错误”、“其他用户修改或删除了您尝试修改的对象”）。

【讨论】：

【解决方案3】：

我强烈反对吞下异常的做法。这是浪费大量时间调查问题根源的最佳方式。当我最终在一个空的 catch 子句中找到隐藏的异常时，我有很多 wtf 时刻。我同意 Thorbjørn 的观点，即大多数时候你都有一个顶级尝试。在其中我发现自己使用了许多可能引发异常的方法，并且为了避免错误处理代码，我更喜欢在顶部捕获中捕获异常。
关于中心化，我认为你的日志文件应该足够中心化。

【讨论】：