java异常的合理寿命是多少？

Question

维护对异常的引用以供以后使用是否合理，或者在比抛出/捕捉交互更长的时间内保留对异常的引用是否存在陷阱？

例如，给定以下代码：

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中Throwable的源代码，似乎有一个JDK6中没有的新的四参数公共构造函数，可以在构造时不调用fillInStackTrace()的情况下创建Throwable。)

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

Answer 1

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

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

Answer 2

我建议你基本上应该像对待任何具有“后端本地代码/存储”的对象一样对待它。如果您需要保留对少数异常的引用，例如，为了“记住”某个特定方法是从哪里调用的，那么不要害怕这样做。另一方面，在没有以某种方式“监控情况”的情况下，不要继续保留数十万个这样的项目。

Answer 3

在两种常见的情况下，对异常的引用超出了它们的直接编程相关性：

当传递给日志记录frameworks

• When时，

1. 被传播出容器上下文，通常在适应适当的form

之后返回到远程应用程序