我是一名绿色开发人员，试图在大型多层 Java 应用程序中获得错误处理的句柄 (har-har)。在很多情况下，我认为通过多层链接异常是一个好主意。例如，当调用最低层的某些外部服务失败时，会导致视图一直出现问题：
最重要的异常，我真正想检查的堆栈跟踪，是链中的最后一个；我提出了一个错误的请求，我需要修复 foo 的格式。但是当我让这个异常通过层冒泡时，很好地链接在对每一层有意义的异常中......当我最终捕获并记录这个东西时，默认的日志记录行为总是向我展示关于最外层异常的大量细节，并且可能是 5 行堆栈跟踪的根本原因。
这让我想在异常发生时记录它们，并让它们冒泡，但你最终会记录大多数事情两次；它们何时发生以及何时最终被抓住。
这里的最佳做法是什么？
我会推荐一种不同的异常管理方法。在应用程序的最顶层（如请求入口点）创建一个 try catch 块来调用任何运行时异常。最好有 2 个 catch 块： - 用于特定于应用程序的（业务）异常 - 用于其余的（异常）
正如您所看到的，您需要介绍自己的异常类型，您将对其进行扩展以针对不同目的创建不同的异常。例如，您可以为应用程序的每一层、每个集成等创建自定义异常。使用未经检查的异常，因为它们都将在顶层处理。当发生任何异常情况（捕获低级异常）时，您应该： - 放置与业务上下文相关的描述（例如“无法从数据库加载帐户数据” - 添加原始异常的描述（例如“原始错误：与数据库的连接失败”） - 将原始异常传递给您的异常，以免丢失跟踪 - 抛出并忘记。换句话说，顶级 catch 块负责适当地处理它（回滚事务，
很好的问题，我很好奇你会得到其他答案。
我倾向于采取“越多越好”的方法，并在每一步都记录下来。这会产生大日志吗？是的，但是当您在大型 Java 应用程序中调试问题时，您会感谢您拥有的每一行日志。还有一些工具（至少是grep, awk, sedtrio）可以帮助您过滤大文件。
另一种技术是编写此日志记录代码，但将其关闭（如果您使用的是 log4j 之类的东西，请关闭该TRACE级别）。这样，如果您遇到问题，您可能没有可用的日志，但这是一个单行更改（以降低日志记录阈值）并且您开始生成大量数据以进行调试。
与前面的技术相结合，大多数日志库（在这里我再次依赖我对 log4j 的知识）允许您调整不同 java 包的日志级别。这意味着您可以将所有这些“catch and rethrow”日志行写为跟踪，并在WARN将上层包保持在DEBUGor时关闭低级包的日志记录TRACE。