如何在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