Question

维护对异常的引用以供以后使用是否合理，或者是否存在使异常引用持续时间远远超过throw / catch交互的缺陷？

例如，给定代码：

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

假设我的程序在JVM中创建了一个具有生命周期的东西，那么Thing是否存在与lastException保持延迟引用有关的任何正确性问题？在JDK7中，这一切都发生了变化吗？（在OpenJDK7中查看Throwable的源代码，看起来有一个新的四参数公共构造函数不在JDK6中，可以在构造时不创建一个Throwable而不调用fillInStackTrace（）。）

如果MyException下的任何链接异常都引用了对象，是的，这会阻止这些对象被垃圾收集，但假设我没关系，是否有任何陷阱需要注意？

Answer 1

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

Answer 2

Throwable是一个成熟的Java对象，只要有人引用它就会持久存在。我已经有一段时间了，因为我在Throwable里面，但是我想不出任何可能反过来保留对堆栈跟踪中方法的类别（只是可能）的引用。但是，堆栈跟踪本身确实消耗了大量的存储空间。

所以它与任何其他中等大小的物体没有什么不同。并且在JVM的生命周期中保留一个例外似乎完全不合适。（如果您保留了所有异常的记录，那可能会有点多。）

Answer 3

有两种常见案例表明例外情况超出了其直接的程序相关性：

传递给日志框架时
当从容器上下文传播出来时，通常在适应合适的表单后返回到远程应用程序

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

3 个答案: