当记录一个包装的异常时，你通常会得到一个关于包装器的长堆栈跟踪，如果有空间的话，还有几行实际的根本原因。但根本原因是我想阅读其堆栈跟踪的异常！
我将我的应用程序中的大多数异常包装在我控制的自定义异常中。（在下面的背景中对此进行推理。）为了解决这个日志记录问题，让我的自定义包装异常在构造时简单地删除它们的大部分堆栈跟踪是否合理？
如果我在构造包装器时删除了大部分堆栈跟踪，那么所有内容都会被精美地记录下来：log4j 似乎打印了 n 行关于异常及其原因的日志，并且将包装器的堆栈跟踪截断为 1 个元素为大量关于根本原因的堆栈跟踪。
我想不出任何情况，我想知道的可能不仅仅是第一行跟踪，但有些事情让我对删除堆栈跟踪信息感到困惑。我缺乏经验，我无法弄清楚我的直觉是否正确，或者我只是对不寻常的情况感到不舒服。谁能告诉我这可能有什么问题？
相关的背景：
我试图在大型 java webapp 中找出一个合理的第一次通过体面的错误处理。我目前的计划是在异常发生时将异常包装在自定义异常中，然后让它们冒泡到记录它们的顶层。（我想使用我的自定义包装器为我看到的每个异常附加一个唯一的 ID，这样我就可以将该 ID 传播到 UI 并在事后很长时间内轻松找到相关日志。）
这是一个与何时记录链式异常密切相关的后续问题？，我担心如何记录链式异常，以便获得更多关于实际原因的信息，而不是一堆关于后续包装器的无用堆栈跟踪。其中一个建议——不要链接所有层，而是让异常冒泡到我可以控制日志记录的顶层——是合理的，只要它们到达顶层，就很容易将代码放在一个地方记录根本原因，而不是包装。但是，如果我有理由捕获并记录这些异常之一，我就会再次陷入默认的日志记录行为。