【0】README

0.1） 本文描述+源代碼均 轉自 core java volume 1， 旨在理解 java異常——分析堆棧跟蹤元素+使用異常機制的技巧 的相關知識；

---

【1】分析堆棧跟蹤元素相關

1.1）堆棧跟蹤： 它是一個方法調用過程的列表， 它包含了程序執行過程中方法調用的特定位置；
1.2）調用Throwable 類的 printStackTrace 方法訪問堆棧跟蹤的文本描述信息；

Throwable t = new Throwable(); ByteArrayOutputStream out = new ByteArrayOutputStream(); t.printStackTrace(out); String descriptoin = out.toString();

1.3）更靈活的方法是使用 getStackTrace 方法，它會得到 StackTraceElement對象的一個數組， 可以在你的程序中分析這個對象數組：

Throwable t = new Throwable()； StackTraceElement[] frames = t.getStackTTrace() ; for(StackTraceElement frame : frames )analyze frame

1.4）StackTraceElement類：含有能夠獲得文件名和當前執行的代碼行號的方法；同時， 還有能夠獲得類名和方法名的方法；
1.5）看個荔枝（靜態的Thread.getAllStackTrace）方法， 它可以產生所有線程的堆棧跟蹤， 下面給出這種方式的具體步驟：

Map<Thread, StackTrace[]> map = Thread.getAllStackTraces(); for(Thread t : map.keySet) {StackTraceElement[] frames = map.get(i);analyze frames; }

• API java.lang.Throwable 1.0
  Throwable(Throwable cause)
  Throwable(String msg, Throwable cause) ： 給定的原因構造一個 Throwable 對象；
  Throwable initCause(Throable cause)：將這個對象設置為原因。 如果這個對象已經設置為原因， 則拋出異常；返回this 引用；
  Throwable getCause()：獲得設置為這個對象的原因的異常對象。如果沒有設置原因， 則返回 null；
  StackTraceElement[] getStackTrace() ： 獲得構造這個對象時調用堆棧的跟蹤；
  void addSuppressed(Throwable t) ： 為這個異常增加一個抑制異常， 這出現在帶資源的try 語句中， 其中t 是close方法拋出的一個異常；

• API lang.Exception
  Exception(Throwable cause)
  Exception(String msg, Throwable cause)：用給定的原因構造一個異常對象；

• API java.lang.RuntimeException
  RuntimeException(Throwable cause)
  RuntimeException(String msg, Throwable cause) ： 用給定原因構造一個 RuntimeException 異常；

• API java.lang.StackTraceELement
  String getFileName()： 返回這個元素運行時對應的源文件名， 如果這個信息不存在， 返回null；
  int getLineNumber()： 返回這個元素運行時對應的源文件行數。如果不存在， 返回-1；
  String getClassName()：返回這個元素運行時對應的類的全名；
  String getMethodName()：返回這個元素運行時對應的方法名。 構造器名是， 靜態初始化器名是 ， 這里無法區分同名的重載方法；
  boolean isNativeMethod():如果這個元素運行時在一個本地方法中， 則返回true；
  String toString()： 如果存在的話， 返回一個 包含類名， 方法名， 文件名和行數的格式化字符串；

---

【2】使用異常機制的技巧

2.1）異常處理不能代替簡單的測試：

如以下代碼或者是： if(!s.empty()) s.pop(); 或者是： try {s.pop(); } catch(EmptyStackException e) {}

• 我們發現， 調用 isEmpty()的運行時間為 646ms ， 而捕獲 EmptyStackException 的運行時間為 21739 ms, 所以，我們可以看出， 與執行簡單的測試相比， 捕獲異常所花費的時間大大超過了前者，
• 因此使用異常的規則是：只在異常情況下使用異常機制；

2.2）不要過分地細化異常

• 很多coder 吧每一條語句都分裝在一個獨立的 try 語句塊中；因此， 有必要將整個任務包裝在一個try 語句塊中，這樣， 當任何一個操作出現問題時， 整個任務都可以取消了；

2.3）利用異常層次結構

• 2.3.1）不要只拋出RuntimeException異常，應該尋找更加適當的子類或創建自己的異常類；
• 2.3.2）不要只捕獲Throwable 異常， 否則，會使代碼更難讀和維護；
• 2.3.3）考慮已檢查異常與未檢查異常的區別。因為已檢查異常本身就很龐大， 不要為邏輯錯誤拋出這些異常；
• 2.3.4）將一種異常轉換為另一種異常時不要猶豫。例如， 在解析某個文件的一個整數時， 捕獲 NumberFormatException 異常， 然后將它轉換為 IOException 或 MySubSystemException的子類；

2.4）不要壓制異常， 在java中， 往往強烈地傾向于關閉異常

• 如果編寫了一個調用另一個方法的方法， 該方法有可能100年才拋出一個異常， 那么編譯器會因為沒有將這個異常列在throws 表中產生抱怨。 而沒有將這個異常列在其中的原因是 編譯器將會對所有調用這個方法的方法進行異常處理的考慮， 因此， 應該將這個異常關閉；

public Image loadImage(String s) {try{code that threatens to throw checked exceptions}catch(Exception e){}// so there }

• 現在， 這段代碼就可以通過編譯了；

2.5）在檢查錯誤時， 苛刻要比放任好

• 如， 當棧空時， Stack.pop（） 是返回一個 null ， 還是拋出一個異常？ 我們認為： 在出錯的地方拋出一個 EmptyStackException 異常要比在后面拋出一個 NullPointerException 要好；

2.6）不要羞于傳遞異常

• 如， FileInputStream 構造器或 readLIne方法， 這些方法就會本能地捕獲這些可能產生的異常， 其實， 傳遞異常要比捕獲這些異常更好：

public void readStuff(String filename) throws IOException {InputStream in = new FileInputStream(filename);...... }

• 讓高層次的方法通知用戶發生了錯誤， 或者放棄不成功的命令更加適宜；

總結

以上是生活随笔為你收集整理的java异常——分析堆栈跟踪元素+使用异常机制的技巧的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。