如何在eclipse上显示完整的堆栈跟踪？

我正在使用Eclipse来调试Java应用程序。某处在代码中，我得到一个异常和堆栈跟踪：如何在eclipse上显示完整的堆栈跟踪？

Caused by: java.io.EOFException: The connection has been reset while reading the header 
    at com.gemstone.gemfire.internal.cache.tier.sockets.Message.fetchHeader(Message.java:583) 
    at com.gemstone.gemfire.internal.cache.tier.sockets.Message.readHeaderAndPayload(Message.java:599) 
    at com.gemstone.gemfire.internal.cache.tier.sockets.Message.read(Message.java:542) 
    at com.gemstone.gemfire.internal.cache.tier.sockets.Message.recv(Message.java:1029) 
    at com.gemstone.gemfire.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:158) 
    at com.gemstone.gemfire.cache.client.internal.AbstractOp.attempt(AbstractOp.java:363) 
    at com.gemstone.gemfire.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:229) 
    at com.gemstone.gemfire.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:321) 
    at com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:646) 
    at com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:108) 
    ... 11 more

如何得到整个堆栈，而不是... 11 more？

来源

2011-09-29 Luchian Grigore

Eclipse控制台窗口应该显示整个异常。这个痕迹在哪里打印出来？在处理Web应用程序时，我在浏览器中看到了像这样的有限痕迹，但从未在控制台中记录有限的痕迹。 – cdeszaq

我不知道，这就是我想找到的。事情是我的断点没有被激活，所以我无法找到确切的地方。 –

你是什么意思？我所问的只是“你在哪里看到这个”？它是否属于Eclipse IDE界面（特别是控制台）的一部分，还是显示在其他某个窗口或文件中？ – cdeszaq

你有整个堆栈。

这只是堆栈跟踪的一部分。直接在这之前是另一块。看看这一条的底线，以及上一条的最上面一行。你会看到他们匹配。堆栈跟踪以不以“由...引发”开头的部分开始。

“引起的”异常隐藏了堆栈跟踪的一部分，这些堆栈跟踪的父级中是堆栈跟踪条目的逐字副本。换句话说，Java不会将每个原因的整个堆栈都显示为main（） - 它只是显示您尚未看到的内容。请参阅Throwable.printStackTrace() documentation。

当您在创建Throwable时提供原因时会填充“由...引起”。看看它的构造函数。这是在一段代码捕获一个低级异常然后想重新抛出它作为一个不同的异常类时完成的。

来源

2011-09-29 13:12:02

我不完全明白... –

@Luchian - 这只是堆栈跟踪的_part_。直接在这之前是另一块。看看这一条的底线，以及上一条的最上面一行。你会看到他们匹配。堆栈跟踪_began_的部分不以“由...引发”开头。 –

没错，所以我猜我被卡住了。我想早些时候发现这个例外。事情是，我设置了一个断点，以明确抛出异常，但它没有触发... –

正如埃德所说，它显示了整个堆栈，但是遗漏了你已经看到的信息。见Throwable#printStackTrace()

从那里报价：

注意包含字符线的存在 “...”。这些行指示此异常的堆栈跟踪的其余部分与（“封闭”异常）引起的异常的堆栈跟踪的底部指定数量的帧匹配。此速记可以大大减少长度在一个包装的异常是从相同的方法“致病异常”抛出的常见情况下，输出的被捕捉

通常异常缠绕;创建另一个例外作为原因：

try { 
    // something which causes an Exception 
} catch (Exception e) { 
    throw new SpecificException("help", e); 
}

在这种情况下，显示堆栈跟踪将创建... 11更多，你看到。

来源

2011-09-29 13:20:58

我还从未见过，但试试这个

public void problemFunction(){ 
    try{ 
     //your code 
    catch(Exception ex){ 
    ex.printStackTrace(); 
    } 
}

或

public void problemFunction(){ 
    try{ 
     //your code 
    } 
    catch(Exception ex){ 
    System.out.println(ex); 
    StackTraceElement[] arr = ex.getStackTrace(); 
    for(int i=0; i<arr.length; i++){ 
     System.out.println(arr[i].toString()); 
    } 
    } 
}

来源

2011-09-29 13:21:15

我认为这意味着Exception被抓获并包装成另一个次printStackTrace被称为前。

尝试找出以下程序的输出为更好地理解：

public class PrintStackTrace { 

    public static void main(String[] args) { 
     try { 
      level1(); 
     } catch (Exception e) { 
      e.printStackTrace(); 
     } 
     try { 
      level2(); 
     } catch (Exception e) { 
      e.printStackTrace(); 
     } 
    } 


    static void level2() throws Exception { 
     try { 
      level1(); 
     } catch (Exception e) { 
      throw new Exception(e); 
     } 
    } 

    static void level1() throws Exception { 
     try { 
      throwingMethod(); 
     } catch (Exception e) { 
      throw new Exception(e); 
     } 
    } 

    static void throwingMethod() throws Exception { 
     throw new Exception("throwingMethod"); 
    } 

}

来源

2011-09-29 13:38:20

以上的答案是不准确的，每个堆栈显示“造成”的话时间就意味着异常经历一种或多种方法直到它被抓住，然后再次抛出。这可能会发生很多次，堆栈跟踪不是一个循环，它是一个单一的方向，所以不，顶部的东西并不涉及底部的东西，最重要的部分是底部的东西是异常的根本，所以，如果你将有：

异常类主：等等等等等等... 的代码行... 造成FileNotFoundException异常 ...的代码行... 引起：MalformedURLException ...代码行... 引起：NullPointerException

然后你不想在FileNotFoundException这么多的焦点，但你想要重点更多关于NullPointerException。就像说你有一个带有文件名的属性文件。如果不小心使用了mykey，要查找属性“myKey”，那么propertiesResource将返回一个null值，然后它将通过所有代码行（希望）一直抛出到最后一个catch块所在的应用程序。。。在这个piont中，它将被“包装”而不是一个nullException，而是一个FileNotFoundException。。。

来源

2012-07-29 18:31:34 bill