AbstractMethodError on调用Exception.printStackTrace

Question

在catch子句中，我要打印异常的strack跟踪：

try {
    ...
} catch (Exception exc) {
    exc.printStackTrace();
    ...
}

但在某些情况下，我没有得到堆栈跟踪，而是看到了如下所示：

Exception in thread "pool-1-thread-2" java.lang.AbstractMethodError: java.lang.Exception.printStackTrace()V
    ...

通常，如果库在运行时具有与编译时不同的版本，则会出现此异常，但在本例中，我使用的是Java库中的一个类。printStackTrace是在Throwable中实现的，因此该方法不能在异常或任何派生类中进行抽象。此外，这个AbstractMethodError并不总是被抛出，有时在这个特定的catch子句中还有其他异常(程序流取决于来自文件和当前时间的数据，因此有时会发生其他事情，比如在我自己的代码中抛出的ArrayIndexOutOfBoundsExceptions或IllegalStateExceptions，而不是奇怪的错误)。

因此，问题是:如何才能发生特定的AbstractMethodError？

PS:我在Linux上使用Eclipse，并使用JDK 1.6.0_24作为运行时环境来启动我的应用程序。

编辑：有一个错误(printStrackTrace)，我改正了。我脑子里都想不出来了，跟我的问题一点关系都没有。它是(或应该是)一个独立的应用程序，没有web应用程序，没有Eclipse应用程序，只是一个普通的旧Java应用程序(或多或少)。这个问题也发生在另一台计算机上-- Eclipse、Fedora和JDK 1.6.0_21也是如此。

令我惊讶的是，调用getClass().getName() (但没有尝试过其他方法)确实是可能的，java.lang.ArrayIndexOutOfBoundsException类型是例外。我只是尝试使用OpenJDK 1.6.0 (因为它已经安装在我的系统上)，得到了不同的结果。而不是抛出AbstractMethodError，printStackTrace只打印一个空行，getMessage()返回null (而不是抛出错误)。因此，我不知道异常到底是在哪里抛出的，因为在层次结构中很高的一个尝试捕获块捕获异常只是为了优雅地阻止应用程序的一部分。我可能会在某些点上捕捉到这种异常类型，以了解它的来源。但这并不能解释异常本身的奇怪行为。

编辑2:终于找到了这个问题。事实证明，这是我昨天在同一条直线上已经想到的一个例外，但有时这个异常本身表现得很奇怪。我在一个get(int)上调用List (更准确地说，它是使用Collections.unmodifiableList(List)包装的ArrayList )，其索引是-1 (这是初始值，在循环中这个索引应该被更改，但它不会因为任何原因而改变)。至少现在我知道该在哪里修复ArrayIndexOutOfBoundsException，但我仍然不知道为什么异常本身表现得很奇怪。

编辑3: --我尝试了Throwable.class.getMethod("printStackTrace").invoke(exc);而不是exc.printStackTrace();，得到了java.lang.NoSuchMethodError: java.lang.Throwable.printStackTrace()V而不是java.lang.AbstractMethodError。我还尝试使用javac和jar从shell编译java文件(只有一个异常来自于库，因为手动编译所有jars会很繁琐)。结果是一样的。如果我自己在这一行抛出一个IndexArrayOutOfBoundsException，堆栈跟踪就会很好地打印出来。也许我必须希望，这个问题是非常罕见的，永远不会发生在其他地方。

Answer 1

据我所知，您已经在Eclipse中启动了应用程序。这可能是因为EclipsewithEclipseand专用类加载器的模块化:用于运行应用程序的OSGi层次结构可能导致无效的链接。这主要取决于您所关注的异常类以及应用程序类路径中包含了哪些jar文件--您自己的jar文件可能与Eclipse本身使用的jar文件发生冲突。你能提供更多的细节吗？

我想您是通过"java应用程序“运行配置启动它的。您是否选中了“包含系统库”或“包含继承的主”之类的复选框或任何其他选项？

顺便说一句，您的应用程序最终将作为一个独立的Java虚拟机运行，并且它应该在这个上下文中运行得非常好。

如果不是这样的话，使用-verbose:class命令行选项运行您的java应用程序，并在崩溃前检查最新的输出行，您可能会得到关于冲突库的线索(与编译时不同)。