將本地的程式碼寫好，執行的時候，對於新手的我們難免會出現各種報錯資訊，以下是我在專案過程中：定位錯誤資訊的幾種方式。

一、最原始的-控制檯報錯的資訊

透過檢視控制檯報錯資訊，將報錯內容翻譯出來（透過多次專案編碼的過程中，大部分報錯資訊都差不多，可以記住一些常見的英文單詞，以便下次可以快速的定位問題），這樣基本上就可以將問題定位出來，這也是最好解決的狀況，也是表明你是菜鳥的重要體現（不過沒有關係，下次注意就好了，成長是需要一個過程的）。

二、初中級-使用debug定位+try catch捕獲異常資訊

該方法主要是針對原生代碼可以啟動，頁面也可以正常顯示，某些功能不能正常實現的問題。首先確保專案是用debug起的，將具體的方法程式碼找到，打上斷點，找到具體的報錯的地方，使用try-catch將異常資訊打印出來，透過控制檯檢視異常資訊，定位問題。（該方法主要是適用於自己寫的需求程式碼，也是開發過程中最常用的定位問題手段）

三、中級階段-檢視eclipse安裝目錄下的log日誌資訊

這個手段也是我們在開發過程中常用的，我們可以透過檢視log日誌看到具體報錯資訊（我在專案中，一般是用來定位頁面報錯資訊，就是頁面打不開或者報錯），在eclipse安裝目錄下找到一個.log檔案，用一個文字編輯器開啟（我使用的是EditPlus），先將原來的日誌資訊刪除，然後在重新點開頁面，使用EditPlus的話點選重新載入就可以看到新的報日誌資訊，將error的資訊選中，定位error就好了。

四、高階階段-使用xshell檢視日誌資訊

如果你們公司專案每個方法進出都記錄了操作日誌或者info日誌，你可以使用xshell檢視錯誤資訊，該方法一般是不跑原生代碼，直接定位環境上的錯誤資訊（大專案的時候）。

總的一句話，主要我們在專案中經常性的總結，隨著接觸的專案需求越來越多，我們定位問題的速度也是越來越快的，記住：千里之行始於足下，堅持到最後的，才能夠笑到最後！

一般有這幾種方法：

1.透過輸出語句，來確定錯誤語句位置，比如System. out. println（“------------------”），在程式上下多處加入此語句當然為了可以適當修改比如橫線換成#。看看控制檯的列印，那塊沒有沒有列印，那麼它上面程式碼有錯誤。這種不能看到詳細資訊，比如變數的傳遞。

3.透過開發工具比如eclipse，在方法下面打一個斷電，透過debug執行，來除錯程式碼，此方法也是程式設計師經常使用的方法，可以清楚看到變數的傳遞，方法呼叫，包括閱讀原始碼經常用到。此方法如果走的太快了，跳過去，可能要重新執行一遍debug。

已經出錯了，那首要做的就是解決掉這個問題，至於定位錯誤的技巧，我覺得這個要根據你的情況來，是生產環境？測試環境？還是本地？

生產環境出錯

這種情況的報錯，一般都是在不經常犯錯的地方丟擲了異常，因為既然是生產環境，那麼在程式使用前，一定是至少經過開發本地測試、測試人員驗證、正式上線三個步驟。這三個步驟以後，一般常規的錯誤肯定已經被解決了。那麼現在出錯的原因，多半就是一些極其特殊的情況，比如：客戶騷操作、機房網路策略異常、時間日期跨度（有些bug只會出現在年頭或者年尾）。排查的方法首先就是看常規日誌有沒有明顯報錯，結合記錄的客戶操作類日誌，及資料庫資料更新日誌進行排查。

測試環境出錯

這種情況下出錯，相比生產環境要好很多，因為只是測試環境，不至於那麼緊張。解決這類問題，可以採用“順藤摸瓜”的方法，首先還原報錯產生的條件，什麼情況下會出錯誤，根據操作步驟，我們可以很快定位到出錯的程式碼塊，仔細排查程式碼邏輯，到底是哪裡有問題。測試環境出錯，在處理問題的時間上相比正式環境，是很有優勢的，加上可以還原，所以處理問題也更容易。

本地開發出錯

如果是自己原生代碼出錯，那就直接採用最簡單快捷的方式了，程式碼除錯。使用編輯器自帶的除錯功能，加上斷點，一步步走程式碼邏輯，檢視各處程式碼值是否正常。一般來講，本地開發最常見的錯誤莫過於空指標異常了，往往一番加斷點打日誌排查後，發現是自己寫的小bug。相比上面兩種情況，本地是最好解決的。

定位錯誤最普遍的方式就是日誌分析，姑且不談是程式碼的執行環境（生產、測試、本地）。

這個問題可以暫時理解為透過日誌定位錯誤有哪些技巧？

1、日誌分類一定要做，分類的維度有很多種，登入型的，許可權型的，業務型的，資料庫操作的等等。

2、列印日誌要完全，時間，類名，詳細的錯誤堆疊資訊，還可以加上一些關鍵引數值，因為錯誤有時候不一定是崩潰日誌，也有可能是業務異常，這些關鍵引數值能給你分析業務帶來有效的指引。

3、對於分散式系統可以考慮上ELK日誌分析系統。ELK日誌系統介紹：

ELK分別是Elasticsearch、Logstash、Kibana三個開源框架縮寫。

Elasticsearch：開源分散式搜尋引擎，提供儲存、分析、搜尋功能。特點：分散式、基於reasful風格、支援海量高併發的準實時搜尋場景、穩定、可靠、快速、使用方便等。它可以接收蒐集的海量結構化日誌資料，並提供給kibana查詢分析

Kibana：開源日誌報表系統，對elasticsearch以及logstash有良好的web頁面支援。

一個簡單的ELK應用架構圖：

圖來網，侵刪。

4、補充一點心得之談，出錯了以後靜下心來仔細思考為什麼出現錯誤，最好的解決和最快的解決方式都有什麼，主動給出方案建議利弊，會很出彩。

一般有這幾種方法：

1.透過輸出語句，來確定錯誤語句位置，比如System. out. println（“------------------”），在程式上下多處加入此語句當然為了可以適當修改比如橫線換成#。看看控制檯的列印，那塊沒有沒有列印，那麼它上面程式碼有錯誤。這種不能看到詳細資訊，比如變數的傳遞。

3.透過開發工具比如eclipse，在方法下面打一個斷電，透過debug執行，來除錯程式碼，此方法也是程式設計師經常使用的方法，可以清楚看到變數的傳遞，方法呼叫，包括閱讀原始碼經常用到。此方法如果走的太快了，跳過去，可能要重新執行一遍debug。

日誌日誌日誌。

線上問題很難定位，加了日誌會幫助很快找到出bug的地方。還有就是加一個報警的系統。當程式出現異常被catch的時候或者直接throw的時候會透過郵箱.簡訊的方式提醒你線上出現了問題。能夠第一時間知道系統出問題了……

在線上加日誌最好debug，這樣不會在線上列印很多日誌，影響機器cpu。我們定位問題的時候將日誌級別調為debug。然後排查問題。

快速高效的排查問題。

希望大家線上永無bug

棧資訊就能看到哪裡出錯了，

日誌資訊也能有幫助

Debug程式

Jvm自帶的命令比如，jps,jstat,jmap等

1 控制檯報錯的資訊

透過檢視控制檯報錯資訊，將報錯內容翻譯出來（透過多次專案編碼的過程中，大部分報錯資訊都差不多，可以記住一些常見的英文單詞，以便下次可以快速的定位問題），這樣基本上就可以將問題定位出來，這也是最好解決的狀況，也是表明你是菜鳥的重要體現（不過沒有關係，下次注意就好了，成長是需要一個過程的）。

2 使用debug定位+try catch捕獲異常資訊

該方法主要是針對原生代碼可以啟動，頁面也可以正常顯示，某些功能不能正常實現的問題。首先確保專案是用debug起的，將具體的方法程式碼找到，打上斷點，找到具體的報錯的地方，使用try-catch將異常資訊打印出來，透過控制檯檢視異常資訊，定位問題。（該方法主要是適用於自己寫的需求程式碼，也是開發過程中最常用的定位問題手段）

3 檢視log日誌資訊

這個手段也是我們在開發過程中常用的，我們可以透過檢視log日誌看到具體報錯資訊，用一個文字編輯器開啟（我使用的是EditPlus），先將原來的日誌資訊刪除，然後在重新點開頁面，使用EditPlus的話點選重新載入就可以看到新的報日誌資訊，將error的資訊選中，定位error就好了。

4 使用xshell檢視日誌資訊

如果你們公司專案每個方法進出都記錄了操作日誌或者info日誌，你可以使用xshell檢視錯誤資訊，直接定位環境上的錯誤資訊（線上專案）

總的一句話，主要我們在專案中經常性的總結，隨著接觸的專案需求越來越多，我們定位問題的速度也是越來越快的，記住：千里之行始於足下，堅持到最後的，才能夠笑到最後！

一般有這幾種方法：

1.透過輸出語句，來確定錯誤語句位置，比如System. out. println（“------------------”），在程式上下多處加入此語句當然為了可以適當修改比如橫線換成#。看看控制檯的列印，那塊沒有沒有列印，那麼它上面程式碼有錯誤。這種不能看到詳細資訊，比如變數的傳遞。

3.透過開發工具比如eclipse，在方法下面打一個斷電，透過debug執行，來除錯程式碼，此方法也是程式設計師經常使用的方法，可以清楚看到變數的傳遞，方法呼叫，包括閱讀原始碼經常用到。此方法如果走的太快了，跳過去，可能要重新執行一遍debug。

定位分析錯誤能力是一個合格的Java程式設計師應該必須具備的能力；通俗來講Java程式出錯也分幾種型別：程式碼自身編寫出錯，程式碼邏輯出錯導致編譯出錯不能透過，程式執行時出錯，下面我們來講一下如何處理這些錯誤資訊：

1.程式碼編寫錯誤應該算比較好找出來的錯誤，主要是語法運用，框架使用配置，分層編寫邏輯與注入這幾個地方會出現錯誤一般現階段很多編寫程式碼軟體都會自動提示出來排查晚上就可以了，也比較考驗程式設計師編寫程式碼的功底，一個合格的程式猿一般很容易處理這些問題

2.程式碼編譯錯誤指的是編寫未見錯誤但是編譯不透過，一般情況多數是由，一些依賴等一些配置檔案未正常引入導致的，或者對一些路徑處理不妥當或者是持久層框架註解不當或缺失，物件初始化等很多問題造成，控制檯會對錯誤進行簡單定位自己去排查就可以了，錯誤種類比較多就不一一解釋

3.程式執行時異常範圍比較廣最基礎的就是程式碼環境未配置妥當，缺少配置，多執行緒引入未處理妥當，程式設計不合理，物件重複自身呼叫造成宕機，堆疊異常，或者分散式專案在執行時未配置好專案之間的互相依賴造成種種錯誤，這些異常處理起來比較麻煩需要根據日誌資訊或者測試環境下debug模式按順序一一排查，最終解決錯誤

作為一名合格的程式設計師，快速定位問題、解決Bug絕對是一項核心技能。下面談談自己在工作中常用的定位錯誤技巧。1、適量的Log輸出

對程式中可能出錯的關鍵地方及時記錄日誌。試想沒有Log記錄的程式，線上Bug如何定位？適量的日誌記錄、高效的日誌分析，更多看出一個程式設計師水平的高低。

2、嫻熟的除錯技巧

Javay開發，首推IDEA，至於Eclipse之流的可以永久封存了。下面在這裡重點為大家介紹幾種IDEA常用的除錯技巧，幫你快速定位分析錯誤。

條件斷點

舉個例子，遍歷一個比較大的List的過程，想讓斷點停在某個特定值。那麼該怎麼辦呢？如下圖所示，在斷點的位置，右擊斷點旁邊的小紅點，會出來一個介面，在Condition這裡填入斷點條件即可，這樣除錯時，就會自動停在i=10的位置。

多執行緒除錯

這基本上是每個開發者都繞不過去的一個坎，多執行緒開發的掌握能力，可以說直接決定作為一名Coder你的能力到底如何。

多執行緒程式同時執行時，誰先執行，誰後執行，完全是看CPU心情的，無法控制先後，執行時可能沒什麼問題，但是除錯時就比較麻煩了，最明顯的就是斷點亂跳，一會兒停這個執行緒，一會兒停在另一個執行緒。如果想讓執行緒在除錯時，想按自己的願意來，讓它停在哪個執行緒就停在哪個執行緒，可以在斷點的位置右鍵，如下圖所示：

其中Suspend掛起的條件是按每個執行緒來，而非All。

臨時執行表示式/修改變數執行值

在程式碼的除錯過程中，可能某一異常現象是在特定值特定環境下才會觸發， 這時候如何快速定位問題呢？其實，IDEA早已支援動態修改變數的值，在變數上右擊，然後選擇Set Value，即可完成。

3、程式碼評審、程式碼走讀

其實，這個無論Java或者任何開發語言都是適用的，當然前提是你不僅熟悉整個程式碼流程，更要對整個業務流程瞭如指掌！

當然，IDEA也是支援遠端除錯的，更多的除錯技巧等著大家去探索！多動手，你一定會收穫更多！

1.概述

在本教程中，我們將研究一些高階IntelliJ除錯工具。假定大家已瞭解除錯基礎知識（如何開始除錯，Step Into，Step Over 操作等）。如果不是，請參考本文以獲取更多詳細資訊。

2.Smart

Step Into

在某些情況下，會在一行原始碼上呼叫多個方法，例如 doJob（getArg1()，getArg2()）。如果呼叫單步執行（F7），則偵錯程式將按照JVM用於評估的順序進入方法： getArg1 – getArg2 – doJob。

但是，我們可能要跳過所有中間呼叫，然後直接進入目標方法。聰明的步入行動可以做到這一點。

預設情況下，它繫結到Shift + F7，並且在呼叫時如下所示：

現在我們可以選擇目標方法。另外，請注意，IntelliJ始終將最外面的方法放在列表的頂部。這意味著我們可以透過按Shift + F7 | 輸入。

3.Drop Frame

我們可能意識到，我們感興趣的某些處理已經發生（例如，當前方法引數的計算）。在這種情況下，可以丟棄當前的JVM堆疊框架以對其進行重新處理。

請考慮以下情況：

現在我們處於先前的方法中：

現在，我們可以透過呼叫Step Into重新執行該處理。

4.當前斷點

有時，非私有欄位是由其他類修改的，而不是透過setter修改的，而是直接修改的（第三方庫就是這種情況，我們不控制原始碼）。

在這種情況下，可能很難理解何時進行修改。IntelliJ允許建立欄位級斷點來跟蹤。

它們像往常一樣設定–左鍵單擊欄位行上的左側編輯器裝訂線。之後，可以開啟斷點屬性（在斷點標記上單擊滑鼠右鍵）並配置我們是否對欄位的讀取，寫入或兩者感興趣：

5.記錄斷點

有時我們知道應用程式中存在競爭條件，但不知道它到底在哪裡。要確定它可能是一個挑戰，尤其是在使用新程式碼時。

我們可以將除錯語句新增到程式的原始碼中。但是，第三方庫沒有這種功能。

IDE可以在這裡提供幫助- 它允許設定斷點，這些斷點一旦被擊中就不會阻止執行，而是產生日誌記錄語句。

假設我們有興趣記錄實際的 isInterested 呼叫的引數。

讓我們在目標方法中建立一個非阻塞斷點（Shift +左鍵單擊左編輯器裝訂線）。之後，讓我們開啟其屬性（在斷點上單擊滑鼠右鍵）並定義要記錄的目標表達式：

6.建立標記

當應用程式在斷點處停止並且可以從堆疊幀訪問目標時，可以標記物件。選擇它，然後按F11（“ 標記物件”操作）並定義目標名稱：

7.結論

我們檢查了許多在除錯多執行緒應用程式時可以大大提高生產率的技術。這通常是一項艱鉅的任務，所以在這裡我們不能低估工具幫助的重要性，畢竟不是在寫Bug的路上就是在改Bug的路上（手動狗頭）。

針對這個問題，大致的定位錯誤技巧有這麼幾種吧。

開發階段：

1.控制檯資訊；

2.debug；

3.try...catch...

上線後：

1.日誌檔案；

2.大家elk日誌系統等。

程式出錯是很正常的事情，每天你都會遇到各種各樣的異常，那麼遇到問題應該怎麼定位問題，首先要看控制檯，報的異常是什麼？如果是生產環節，那麼可以看伺服器日誌，模擬出錯，然後定位問題，當然還有一些問題可能是因為程式編寫不規範該加的符號沒有加， 更有甚者可能是因為開發工具或者快取等因素造成錯誤發生，不過做程式只要時間久了，慢慢就有經驗了，遇到錯誤就知道該怎麼解決了，一點建議僅供參考，希望對你有所幫助！

在開發、測試、線上執行的過程中，程式難免會出現問題，如果快速地定位程式的問題，是每個程式設計師的必修課。

01. 日誌是基礎

當程式報錯，最簡單且快速的方法就是查詢日誌中的報錯資訊了；所以我們在敲程式碼的時候，一定不能對 CheckedException 只捕捉不處理。

首先不要忽略異常，第一可以在捕捉到異常後將日誌資訊輸出，要麼透過 Throw 或 throws 向上拋，讓上層的程式碼進行處理；

接上，不要捕捉異常後，輸出完日誌又向上丟擲異常，這樣當查詢定位錯誤時，會產生誤導；

對於捕捉到的異常，最好可以精確地指出具體是什麼異常，而不要用 catch(Exception e) 替代；

如果選擇了輸出異常，那麼就要把異常單獨列印到一個日誌檔案中，否則你很可能需要在一大堆日誌檔案中翻閱查詢；

另外，日誌資訊儘可能的詳細，比如方法的入參、與其他系統互動的報文等等。

如果你能在日誌檔案中快速的找到報錯資訊的話，那麼再定位錯誤程式就容易很多：

通常異常輸出能看到報錯的類、方法、甚至程式碼行數，可以先檢查程式是不是有顯而易見的錯誤；

如果是開發測試環境，可以透過 IDE 進行程式碼除錯，如果錯誤每次都可以復現，那就是一個明顯的 BUG，如果是部分資料有問題，那麼就要分析是程式不嚴謹，還是資料有問題；

如果是生成環境的話，我們很難進行線上除錯，那麼只能透過日誌來進行具體的分析了，條件允許的話，可以把生產環境的資料拿下來進行檢查和除錯。

02. 完善的監控

很多程式設計師會說，我的日誌都很完善了，還需要監控麼？我建議最好是有的，而且監控越完善越好。

首先，透過日誌查詢問題，通常都是業務人員或使用者在操作過程中遇到問題，找到運維和開發之後，我們再去翻日誌；如果有監控的話，可以實時地發現問題，提前解決問題。

第二，現在很多專案都不是單臺部署，應用部署個幾臺、幾十臺甚至幾百臺都很常見，當發現問題之後，人肉翻日誌已經不太現實了，如果有一個日誌平臺的話，那就會方便很多。

第三，很多公司的專案都是分散式架構、微服務架構，越來越多的服務都是鏈路呼叫，A系統調B系統，B系統再調C系統和D系統，這種情況下翻一個服務的訪問鏈路，就需要從幾個系統上拿日誌，人肉運維是很費時費力的。

03. OOM 、CPU 佔用率高等異常分析

上面說到的各種錯誤，基本上是有明確的程式碼問題，不管是程式碼本身的問題，還是資料的問題導致程式碼報錯，另外一種不是“顯性”的異常（最終可能依然是程式碼的問題），比如記憶體使用過高、CPU使用過高、 頻繁 Full GC、OOM 等等，通常這一類的問題不好重現、定位困難。

如果有報錯資訊，首先還是要查詢關鍵報錯資訊，比如 java.lang.OutOfMemoryError: Java heap space，很明顯就是堆溢位；

這時候你需要知道堆裡面存的是什麼，這樣有助於你進行問題的排查：Java 堆用於儲存物件例項，如果有大量的物件無法被垃圾回收機制清除，那麼超過堆容量限制之後，就會發生溢位；

我們可以使用記憶體映像分析工具，對堆儲存快照進行分析；如果有記憶體洩漏，可以透過工具檢視洩漏物件；如果不存在洩漏的話，可以檢查程式碼中是否有遞迴、死迴圈等等。

當然，不同“部位”洩漏和溢位的原因都是不同的，需要具體分析。

如果是 CPU 過高，可以透過系統命令來定位問題：

一般 Java 程式 CPU 過高，可能是這幾種原因：死迴圈、計算比較密集、IO 讀寫高、請求堵塞等等；

透過 top 命令，檢視當前伺服器佔用 CPU 資源最多的程序，得到程序號 PID = 4454；

透過 top -Hp 4454 查詢 4454 程序中各個執行緒的資源使用率；比如有一個執行緒 4492 佔用 CPU 特別高；

透過 printf "%x\n" 4492 命令，把執行緒 id 轉化為十六進位制；4492 的十六進位制是 118c；

使用 jstack 命令列印堆疊資訊：jstack 4454 | grep -10 118c；

根據佔用 CPU 高的執行緒的堆疊資訊，分析對應的程式碼在做什麼操作，並進行最佳化。

一、錯誤的分類

程式執行出錯指的是程式未按照程式預設的邏輯執行，從而造成非預期的結果，具體表現就是報錯中斷或資料錯誤。作為程式設計師，一定要分清哪口鍋是自己的，對於設計中的預設錯誤一定要甩出去，例如：傳入引數不合法、違反業務規則等等。本節，我們只考慮自己的鍋。自己這口鍋裡能裝的錯誤也很多，但是我們不考慮純粹的認為因素造成的執行出錯（例如版本遺漏、配置錯誤等等）。

1、有報錯的錯誤

造成這一類錯誤的原因，主要有：

A. 開發過程不嚴謹，沒有進行必要的判斷或沒有充分的考慮各種可能的分支（這就是為毛好些java規範裡要求if和else要成對出現的原因），這類錯誤裡最為常見的異常就是空指標、下標越界、除數為0等執行時異常了；

B. 記憶體洩露問題。java對指標進行的透明化處理，GC操作大多數時間也由JVM自主完成，但是畢竟記憶體中的資料是程式在執行過程中塞進去的，如果資料的生命週期設計存在問題的話，很容易會造成OOM錯誤。前段時間和一個朋友就聊到了這個問題，他所在公司的一個專案就是因為未及時釋放有效資料導致jvm記憶體佔用持續增高，即使JVM執行FullGC操作後，記憶體佔用率依舊很高，從而導致OOM錯誤。

C. 捕獲的範圍小了，預期外的錯誤未捕獲。在一個專案中就遇到過這種情況，程式只對Exception進行了捕獲，未捕獲Error，導致程式在丟擲了一個Error（那次是一次人為的原因）而導致未回滾資料庫事務，造成了鎖表。

2、沒報錯的錯誤

造成這一類錯誤的原因，主要有：

A. 雖然丟擲了錯誤，但是被吃掉了。就是在catch到Exception後沒有進行任何處理，包括列印日誌。這個的原因就不多說了...說多了都是淚。

B. 程式正常執行完成，但是結果不符合預期。這個原因很可能是程式未對併發安全進行設計。

C. 無限等待，超時時間設定不合理或者死鎖。

二、錯誤的定位

定位錯誤是有一個大概的順序的。

1、檢查有沒有報錯資訊

日誌檔案中登記的錯誤，這個算是最簡單的，在定位錯誤時，也最希望問題在這一步得到確認。在列印異常時，通常會列印異常的呼叫棧資訊，透過呼叫棧資訊就可以很便捷的定位問題了。

2、檢查標準輸出檔案和異常輸出檔案有沒有報錯資訊

Error可能不會列印在日誌檔案中（如果關掉了標準輸出就不會列印了），但是會列印在標準輸出中，前提是沒有把標準輸出也吃掉。通常在出現錯誤時，單單透過檢查日誌來定位問題怕是不足以說明問題，通常還會配合dump檔案進行分析，因此在程式啟動時需要開啟相應引數（-XX：+HeapDumpOnOutOfMemoryError），在JVM出現記憶體溢位異常時Dump出當前的記憶體堆轉儲快照以便後續進行分析。

3、結合系統資源使用情況

如果沒有報錯的資訊，這時候可能需要結合當前的CPU使用率等情況進行分析了。找到最為消耗資源進行針對性的分析，常用的linux命令有：

top （-H -p pid）：找到佔用CPU最高的執行緒ID

jstack：列印程序堆疊資訊，看看死鎖，執行緒啥的

jstat：監視虛擬機器gc之類的功能

jmap：java記憶體映像工具

kill -3：嚇唬jvm用的，讓他生成dump檔案

netstat: 檢視網路連線情況用的

4、看程式碼

前3步的作用都是為了這一步來服務的，當然程式碼也需要結合一些日誌來分析（總不可能一行都沒有吧~）。但是不一定任何時候都能透過前三步找到程式碼方面的蛛絲馬跡的（例如，當沒有日誌且沒有現場時）。咳咳~這時候就體現出程式碼評審的意義了，一些公司在開發過程中非常不注重程式碼的走查和評審工作，開發的時候能用就行，出現問題以後又到處甩鍋，我只能說：可憐了，我的開發小哥！

絕大多數的問題都是因為開發原因導致的，雖然缺陷總是不可避免的，但是為了後期能夠相對工作的輕鬆一點，希望每個開發小夥伴都能有一個良好的編碼規範和日誌規範，以便在出現問題的時候能夠快速定位，避免被“祭天”。

一般有這幾種方法：

1.透過輸出語句，來確定錯誤語句位置，比如System. out. println（“------------------”），在程式上下多處加入此語句當然為了可以適當修改比如橫線換成#。看看控制檯的列印，那塊沒有沒有列印，那麼它上面程式碼有錯誤。這種不能看到詳細資訊，比如變數的傳遞。

3.透過開發工具比如eclipse，在方法下面打一個斷電，透過debug執行，來除錯程式碼，此方法也是程式設計師經常使用的方法，可以清楚看到變數的傳遞，方法呼叫，包括閱讀原始碼經常用到。此方法如果走的太快了，跳過去，可能要重新執行一遍debug。

首先，我們知道Java有3種丟擲異常的形式：throw（執行的時候一定丟擲某種異常物件）, throws（出現異常的可能性，不一定會發生）, 系統自動拋異常。

throw用在一個語句丟擲異常的時候，throw (an instance of exception class)比如一個方法/函數里，try{…}catch(Exception e){throw new ArithmeticException(“XXX”);}finally{…}；

throws則是用在宣告方法可能丟擲異常的時候，throw (exception class)比如public int division(int x, int y) throws ArithmeticException {…}；

系統自動拋異常則是當程式語句出現邏輯錯誤，主義錯誤或型別轉換錯誤的時候，系統自動丟擲異常，比如int a = 5; int b = 0; c = a/b; 這個時候移動會自動丟擲ArithmeticException。

什麼是異常

異常，顧名思義，就是有異於正常狀態，有錯誤發生。而這錯誤會阻止Java當前函式方法的執行。

那麼Java裡面異常的體系是怎麼樣的呢？

1.Java裡面所有不正常類都繼承於Throwable類；而Throwable類包括2類：Error類和Exception類。

2.Error類包括虛擬機器錯誤（VirtualMachineError）和執行緒死鎖（ThreadDeath）。

3.Exception類則是我們在說的異常；包括執行時異常（RuntimeException）和檢查異常；這裡的異常通常是編碼，環境，使用者操作輸入出現了問題。

4.執行時異常（RuntimeException）包括以下4種異常：空指標異常（NullPointerException），陣列下標越界異常（ArrayIndexOutOfBoundsException），型別轉換異常（ClassCastException），算術異常（ArithmeticException）。

空指標異常：

陣列下標越界異常：

型別轉換異常：

算術異常：

5.最後剩下的檢查異常則是剩下各種異常的集合；這裡發生異常的原因有很多，檔案異常（IOException），連線異常（SQLException）等等；和執行時異常不同的是，這裡的異常我們必須手動在程式碼裡新增try…catch…(finally…)語句來捕獲處理。

今天又瞭解學習到了一些具體的額外的異常：

Throw丟擲異常詳細過程

和throws宣告方法可能會發生異常不同，throw語句則是直接丟擲一個異常。

前面有提到，throw (an instance of exception class)，這裡的一個exception類的例項其實也可以說是一個ExceptionObject（Throwable類或則其子類 的物件；也可以是自定義的繼承自Throwable的直接或間接的異常類）。如果，我們用了throw new String(“異常XXX”); 則會在編譯的時候報錯，因為String 類並不是Throwable類的子類。

接著讓我們回到怎麼用throw語句的階段。

一般我們有兩種方式來用throw：直接在某處會發生異常的地方用throw語句或則用try…catch…finally…語句來捕獲處理異常和關閉釋放資源。

首先是第一種，直接在某處會發生異常的地方用throw語句；這是一種主動的方法，主動丟擲異常去處理。

而第二種，用try…catch…finally…語句來捕獲處理異常和關閉釋放資源 則是被動的方法。try裡面放入可能會發生異常的語句塊，如果在執行期間遇到了異常，則會交給catch來處理異常（catch可以是多個，處理不同的異常），finally則是無論有沒有異常發生，只要加上了就會執行。

首先我們來看第一種方法的函式：

我們的int c = 4/2，其實是正確的；但是我們的throw 語句主動丟擲了異常，那麼程式就會到catch裡面找有沒有這個異常，有的話進行處理。所以我們要主動拋異常的話，要很確信這個程式碼一定會發生異常且後期不太會去變動了（最好放在if條件語句裡）。所以我們得到的結果如下：

接著我們來看第二種方法。我們一開始先測正確的，只是把主動丟擲異常語句給註釋掉：

因為try裡面的語句塊沒有異常，所以只執行了try和finally裡面的語句塊。執行的結果如下：

我們接著來測當try裡面的語句塊有異常，且沒有主動丟擲異常的時候，try會不會捕捉到異常吧：

得到的結果如下，會去處理異常和執行finally裡面的語句塊：

最後深入理解一點try裡面的異常觸發會逐層向上的這個概念。在我們try語句裡主動/被動丟擲異常的時候，程式會調向呼叫者程式（上面的例子裡就是我們自己這個函式；但有的時候我們會在try語句裡執行別的函式比如B，這個函式B裡我們假如觸發了異常，它會調向try語句所在的函式A），尋找和它相匹配的catch語句，執行catch語句裡面相應的異常處理程式；但假如沒有找到相匹配的catch語句，那麼它會再轉向上一層的呼叫程式…這樣逐層向上，直到最外層的異常程式終止程式並打印出stack trace。

參考資料

rollbar.com/guides/java…www.javatpoint.com/throw-keywo…www.geeksforgeeks.org/throw-throw…

本文分享自華為雲社群《Java-throw異常詳解以及過程-雲社群-華為雲》，作者：gentle_zhou。