什么'；java异常的预期寿命是否合理？

保留对异常的引用以供以后使用是否合理，或者保留对异常的引用的时间是否比抛出/捕获交互的时间长得多

例如，给定代码：

class Thing {
  private MyException lastException = ...;
  synchronized void doSomethingOrReportProblem() {
    try {
      doSomething();
    } catch (MyException e) {
      if (seemsLikeADifferentProblem(e, lastException)) {
        reportProblem(e);
      }
      lastException = e;
    }
  }
}

假设我的程序创建的对象的生命周期与JVM一样长，那么维护对lastException的持久引用会涉及到正确性问题吗？这在JDK7中有没有改变？（看看OpenJDK7中要丢弃的源代码，似乎有一个新的四参数公共构造函数不在JDK6中，它可以在构造时不调用fillInStackTrace（）而创建丢弃。）

---

如果MyException下的任何链式异常都引用了对象，是的，这将防止这些对象被垃圾收集，但假设我对此没有意见，那么有什么陷阱需要注意吗？

我建议您基本上应该像对待任何“后端有一些本机代码/存储”的对象一样对待它。如果您需要保留对一些异常的引用，例如“记住”从何处调用特定方法等，那么不要害怕这样做。另一方面，如果不以某种方式“监视情况”，不要继续使用数十万个对象。

一个Throwable是一个成熟的Java对象，只要有人引用它，它就会一直存在。我在Throwable中已经有一段时间了，但我想不出有什么东西可能会反过来保留对堆栈跟踪中方法类以外的引用（只是可能）。然而，堆栈跟踪本身确实消耗了大量的存储

---

所以它和其他中等大小的物体没有什么不同。在JVM的生命周期中保留一个例外似乎一点也不过分。（如果您保存了所有异常的记录，这可能有点过分。）

有两种常见情况，其中对异常的引用超出了其直接的编程相关性：

当被传递到日志框架时

当从容器上下文传播出去时，通常在适应适当的形式后返回到远程应用程序

---

为了使您的代码完全独立于不同的Java版本/实现，为什么不自己编写一个类来存储有关错误的信息，并在遇到错误时对其进行更新呢“seemsLikeADifferentProblem”遍历异常链。创建一个数据结构以基本复制整个链似乎是重复的。CPerkins：我选择将其设置为静态，以使其隐含引用将被维护很长的生命周期（JVM的生命周期）。编辑问题以删除静态并明确说明寿命，这样静态性就不会分散对真实问题的注意力。@das_weezul--保留指向异常对象的指针如何不“独立于”Java版本？