当记录一个包装的异常时，你通常会得到一个关于包装器的长堆栈跟踪，如果有空间则会有几行实际的根本原因。但根本原因是我想要读取其堆栈跟踪的异常！
我在我控制的自定义异常中包含了我的应用中的大多数异常。 （在下面的背景中对此进行推理。）为了解决这个日志记录问题，让我的自定义包装器异常只是在构造时删除大部分堆栈跟踪是否合理？
如果我在构造中删除了包装器中的大部分堆栈跟踪，那么所有内容都会被很好地记录下来：log4j似乎打印了n行日志，关于异常及其原因，并将我的包装器的堆栈跟踪截断为1个元素关于根本原因的大量堆栈跟踪。
我想不出任何我想要知道的东西，而不是第一行的痕迹，但是有些东西只是让我忘记了删除堆栈跟踪信息。我没有经验，如果我的直觉是正确的，或者我对一个不寻常的情况感到不舒服，我就无法理清。谁能告诉我这可能有什么问题？
背景如果相关：
我试图找出一个合理的第一次传递，在大型java webapp中正确的错误处理。我目前的计划是在发生自定义异常时将异常包装起来，然后让它们冒泡到它们被记录的顶层。 （我想使用我的自定义包装器为我看到的每个异常附加一个唯一的ID，因此我可以将该ID传播到UI并在事后很长时间内轻松找到相关日志。）
这是一个与When to log chained exceptions?密切相关的后续问题，我担心如何记录链式异常，以便获得有关实际原因的更多信息，而不是关于后续包装器的一堆无用的堆栈跟踪。其中一个建议 - 不是链接所有层，而是让异常冒泡到我可以控制日志记录的顶层 - 是合理的，只要它们达到顶层，就可以很容易地将代码放在一个地方记录根本原因，而不是包装器。但是，如果我有理由捕获并记录其中一个异常，我再次陷入默认的日志记录行为。
答案 0 :(得分：1)
堆栈跟踪中的“... 101多行”并不意味着堆栈跟踪不完整，因为该功能仅隐藏冗余信息。有关详细信息，请参阅以下问题的编辑和接受的答案：
How do I stop stacktraces truncating in logs
至于你的后续问题：
即使我的日志中的信息都已完整，我宁愿只查看根本原因或根本原因。
据我所知，log4j将堆栈跟踪呈现委托给Throwable.printStackTrace，它不允许自定义格式。但是，它的继承者Logback可以在顶部写出具有根本原因的堆栈跟踪。