?
1.?前提
第一層：遇到異常首先必須告訴自己，冷靜，不要慌。（一看到Bug就心慌，那么武功就施展不了了）
2.?入門級
第二層：遇到Bug，第一潛意識看輸出異常的信息的（控制臺輸出，Junit輸出，頁面輸出），優先將異常輸出在控制臺。
?
建議：遇到JUnit異常輸出，最好轉成控制臺輸出。
如：一下異常如果在Junit查看，不好發現為，只知道是數據庫出錯了。轉成為控制臺異常立刻就看到是缺少了一個字段。
| ? ? |
控制臺的異常更加直觀
| ? ? |
?
?
?
?
第三層：查看異常的第一個關注點：異常的名字，通過異常名字大概可以給異常分類。
如：根據這個異常的名字就知道，異常出現在數據庫操作。
| ? ? |
?
第四層：查看異常的第二個關注點：異常的信息，很多異常的信息已經說明了異常的問題（30%）
?
如：該異常，明眼的同學立刻就知道數據庫操作不成功，問題出在配置少了一個字段。
| ? ? |
?
3.?應用級
第五層：以上操作不能解決，查看異常的第三個關注點：在異常中尋找是否有自己寫的類，定位異常出錯的位置。
如下圖：明顯告訴為，是DataSourceTest.java:23，就是該類的23行出錯了。可以點進去
| ? ? |
| --點擊進去，設置斷點 ? ? |
?
第六層：在該出錯的位置System.out.print()輸出數據，分析數據（可選，如果會斷點跳過該步）
?
第七層：在該出錯的位置，設置調試斷點，根據單步調試，分析斷點輸出的數據。使用watch操作獲得重點關注的數據。（80%）
注意：該步驟，包括在瀏覽器調試js代碼的流程。
重點：
（1）找的異常的代碼位置（通過在異常信息里面找到自己的報錯位置！！）
（2）理解異常和數據的關系（難點）
4.?高手級
第八層：有些問題，出錯是無法設置斷點的，啟動程序就出錯了。而且這種問題，經常這種異常就沒有自己寫的類，斷點調試的功力就被廢了。遇到這種問題，第一意識要想到，這些問題不是Java代碼的出錯，出現這種問題的原因：開發環境出錯，JSP頁面出錯，配置文件、配置類出錯
?
（1）如何判斷是開發環境出錯：看看項目有沒有錯誤警告。
| ? ? |
?
（2）如何判斷是否是頁面出錯：查看頁面異常信息和控制臺
通常頁面出錯，異常會告訴你，哪個頁面出錯。這是很重要的信息。
接著的問題只能根據信息提示解決了
| ? ? |
?
（3）如何判斷是配置文件出錯：查看控制臺信息，有時控制臺找不到想要的。可以通過設置入口斷點的方式。
如：在配置struts.xml配置是否出錯，在Action的方法入口處設置一個斷點。如果都沒有執行代碼邏輯就出錯了，那么可以判斷，就是web.xml獲得strust.xml配置錯了，不可能是代碼出錯。
?
注意：
分析配置文件異常時：
如果網站連啟動都啟動不了的，重點關注web.xml
如果網站可以啟動的關注非web.xml的配置文件 （90%）
5.?骨灰級
第九層：隔離法（99%）
在作為以上所有操作，都無法找到異常的原因，可以使用隔離法。可以分為代碼隔離和業務隔離。
?
（1）代碼隔離法
同一個程序中，根據異常的范圍，停止與異常無關的代碼模塊的執行，并且在代碼執行的流程的各處設置輔助斷點跟蹤。
?
做demo。對原理不太熟悉的代碼。！！！！
?
（2）業務隔離法
分布式開發中，一個系統有多個子系統組成。往往一個業務的實現要調用N個子系統的接口。經常會出現，開發時功能是好的。上線時就出錯問題。遇到這種問題，在前八層的功力都無法分析時，那么就要將各個業務系統隔離分析了。
?
?
?
代碼隔離經常用于
（1）沒有輸出有效異常信息的異常。
（2）出現的異常不是固定的，有時可以有時不可以。
?
?
?
6.?神級
第十層：根據多年積累的經驗。使用直覺，可以立刻定位絕大大部分問題，不需要任何招數。在直接判斷不了再使用以上的方法拆招。
?
?
