Java 何时记录链接异常？

我是一名绿色开发人员，试图在大型多层java应用程序中获得错误处理的句柄（har-har）。在很多情况下，我认为通过几个层链接异常是一个好主意；e、 g.当调用最低层的某个外部服务失败时，会导致视图中的所有问题：

• 已请求Content X，但用户未经授权
  • 原因：授权用户列表为空
    • 原因：用户管理Web服务响应了错误的请求-参数foo的格式必须为'xyz'

最重要的例外，我真的想检查它的stacktrace，是链中的最后一个；我提出了一个错误的请求，我需要修复foo的格式。但是当我让这个异常在各层中冒泡时，很好地链接在对每一层都有意义的异常中。。。当我最终捕获并记录该事件时，默认的日志记录行为总是向我显示关于最外层异常的大量细节，可能还有5行根本原因的stacktrace

这使我想在异常发生时记录它们，并让它们冒泡起来，但大多数情况下都会记录两次；当他们发生和最终被抓住时

---

这里的最佳实践是什么？

好问题，我很好奇你会得到其他答案

我倾向于采取“越多越好”的方法，并记录每一步。这能做大圆木吗？是的，但是当您调试大型Java应用程序中的问题时，您会感谢您拥有的每一行日志。还有一些工具（至少是

grep

、

awk

、

sed

trio）可以帮助您过滤大型文件

另一种技术是编写此日志代码，但将其关闭（如果您使用的是类似log4j的东西，则为

跟踪

级别）。这样，如果您遇到问题，您可能没有可用的日志，但这是一个单行更改（以降低日志阈值），您开始生成大量用于调试的数据

---

与前面的技术相结合，大多数日志库（在这里我再次依赖于我对log4j的了解）允许您调整不同java包的日志级别。这意味着您可以将所有这些“catch and rethrow”日志行写入跟踪，并将较低级别包上的日志记录关闭为

WARN

，而将较高级别的包保持在

DEBUG

或

trace

，我建议使用不同的异常管理方法。在应用程序的最顶层（如请求入口点），创建一个try-catch块来调用任何运行时异常。最好有两个挡块： -针对特定于应用程序（业务）的例外情况 -其余的（例外）

正如您所看到的，您需要引入自己的异常类型，您将扩展该类型以创建不同用途的不同异常。例如，您可以为应用程序的每个层、每个Integration等创建自定义异常。使用未检查的异常，因为它们都将在顶层处理。当出现任何异常情况（捕获低级异常）时，您应： -放置与业务上下文关联的描述（例如“未能从数据库加载帐户数据” -添加原始异常的描述（例如“原始错误：连接到DB失败”） -将原始异常传递给您的异常，以免丢失跟踪

---

-扔掉并忘记。换句话说，顶级catch block负责适当地处理它（回滚事务、显示错误消息或您可能需要的任何其他内容）

对此会有很多意见，但没有“真相”。选择适合您的内容，无论您选择什么，人们都会不同意。（就我个人而言，我喜欢把东西重新缩到最外层并记录在那里）这似乎是一个很好的方法；当我将自定义异常一直冒泡到顶层时，我有一个地方可以将其根本原因传递给记录器。但是如果有地方需要捕获并记录其中一个异常，我将记录包装的异常。截断包装器的stacktrace有什么问题吗只有一行或没有行的概念？我不明白为什么会出现问题，但修改stacktraces对我来说听起来不太正确。