Question

我想知道是否总是必须使用try-catch-error块，如果我想捕获错误那么会使代码混乱。

或者我可以以某种方式定义全局错误捕获器？特别是关于Java EE Webapps。

对于每个未处理的ex，我想登录到特定文件，并向用户显示一般错误页面。

我以为我可以用方面实现这一目标。但是对于要抓住@AfterThrowing的方面，我也必须引入try-catch块。由于没有背景外观的中心级别，我将不得不用trycatches包围每个支持方法。然后方面将采取它们，但我需要抓住一些东西，没有明确的抛出异常。

我怎么能这样做？

Answer 1

您正在寻找declare soft构造。这将把给定的异常包装在SoftException（特定于AspectJ的RuntimeException）中，这样就不需要显式处理它。然后，您可以通过一些AfterThrowing建议来处理所有这些异常。

declare soft仅存在于代码样式AspectJ中（即 - 没有注释）。因此，您需要使用AspectJ编译器编译代码，但如果您愿意，仍然可以使用加载时编织。

这是一个代码片段，展示了如何完成它：

aspect ErrorHandler {
  declare soft : Exception : within(*);
  after() throwing(Exception e) : handler(e) {

    // do something...
  }
}

这将通过您的自定义错误处理程序在系统中路由所有异常。而且您不需要明确地捕获或抛出它们。

它简单而有力。但也许太强大了。我建议改进并更准确地确定哪些例外应该被软化以及需要建议哪些例外，但这是基本的想法。

Answer 2

您不必在每种方法中都这样做。

你不应该抓住一个你无法“处理”的例外。处理不仅仅意味着重新抛出或记录或打印堆栈跟踪。我认为处理意味着实施有意义的恢复策略。

这可能意味着“降压停在这里”：你是在层边界边缘的桥上的甘道夫，并且没有例外。您不希望用户看到令人讨厌的消息，因此您可以捕获并将其发送给朋友，这是一个易于理解的页面，告诉他们下一步该做什么。

最后并不总是必要的，但它非常适合清理文件句柄和数据库游标等资源。

如果你不能处理异常，那么将throws子句添加到方法签名并让调用者弄清楚他们想要做什么就没有羞耻。

Answer 3

在一般情况下，没有机制可以做到这一点 - Java没有你正在寻找的东西。

但是，根据您的具体情况，有可能。

web.xml异常处理程序

web.xml文件允许您定义用于处理指定异常类型的URL。（例如，见http://wiki.metawerx.net/wiki/Web.xml.ExceptionType）由于您正在编写Web应用程序，因此您可以将异常一直抛到顶部，然后以这种方式处理它们。

自定义拦截器

你提到你有背景。根据他们的构建方式，您可以在他们面前放置一个通用代理来捕获和处理您感兴趣的例外。您已用{{1标记了您的问题你可能想看一下Spring AOP Proxies。

可能还有其他方法可以获得您想要的内容，但这取决于应用程序架构的具体细节。

Answer 4

您对异常的控制越精细，调试/提供有意义的消息就越容易。

到哪个程度？我会将其与应用程序的复杂性/预期生命周期联系起来。那些越大，你的处理就越精细。

我看到两种主要方法：

请记住，大多数处理可能只是记录重新抛出异常。

更重要的是，您的Java EE框架很可能在其配置文件中有日志选项（其中许多使用java.util.loggin或log4j）。你可以调整一下;当然，发送到每个日志类别的内容将取决于框架实现（因此可能并非所有ERROR消息都是异常）。