因?yàn)榇a經(jīng)驗(yàn)和見識(shí)等原因，說實(shí)話現(xiàn)在對于異常的使用，我也算是理解甚少。為什么用？什么時(shí)候用？即便是在查閱了部分資料以后，也只能在這里提煉出部分自己能夠理解的，以供參考和討論。

1、使用異常的好處

1.1 隔離常規(guī)代碼和錯(cuò)誤處理代碼

實(shí)際上，我們希望程序不要出現(xiàn)問題，用戶操作永遠(yuǎn)邏輯清晰而正確，一切都按照我們祈禱的那樣運(yùn)行，然而這是不可能的。必然會(huì)有錯(cuò)誤必然會(huì)要我們?nèi)ヌ幚?#xff0c;但是錯(cuò)誤的處理并不是我們代碼的核心。
就像用戶取錢的操作，我們核心的代碼應(yīng)該是賬戶金額變動(dòng)和更新，而過程中可能出現(xiàn)的各種意外如余額不足，取錢超出額度等夾雜在我們的正常邏輯里，代碼必然顯得混亂，可讀性差。而異常機(jī)制將這些意外情況剝離了出來。
我們用個(gè)簡單的例子來說明：
//假如我們要實(shí)現(xiàn)將一個(gè)文件讀入內(nèi)存，實(shí)際上真正核心只需要下面5步 readFile {open the file;determine its size;allocate that much memory;read the file into memory;close the file; }81//假如我們要實(shí)現(xiàn)將一個(gè)文件讀入內(nèi)存，實(shí)際上真正核心只需要下面5步 ?2readFile {3 ? ?open the file;4 ? ?determine its size;5 ? ?allocate that much memory;6 ? ?read the file into memory;7 ? ?close the file;8}
//為了處理文件不能打開、不能確定文件大小、內(nèi)存分配不足等可能出現(xiàn)的意外，我們可能最終寫成如下 errorCodeType readFile {initialize errorCode = 0;open the file;if (theFileIsOpen) {determine the length of the file;if (gotTheFileLength) {allocate that much memory;if (gotEnoughMemory) {read the file into memory;if (readFailed) {errorCode = -1;}} else {errorCode = -2;}} else {errorCode = -3;}close the file;if (theFileDidntClose && errorCode == 0) {errorCode = -4;} else {errorCode = errorCode and -4;}} else {errorCode = -5;}return errorCode; }311//為了處理文件不能打開、不能確定文件大小、內(nèi)存分配不足等可能出現(xiàn)的意外，我們可能最終寫成如下2errorCodeType readFile {3 ? ?initialize errorCode = 0;4 ? 5 ? ?open the file;6 ? ?if (theFileIsOpen) {7 ? ? ? ?determine the length of the file;8 ? ? ? ?if (gotTheFileLength) {9 ? ? ? ? ? ?allocate that much memory;10 ? ? ? ? ? ?if (gotEnoughMemory) {11 ? ? ? ? ? ? ? ?read the file into memory;12 ? ? ? ? ? ? ? ?if (readFailed) {13 ? ? ? ? ? ? ? ? ? ?errorCode = -1;14 ? ? ? ? ? ? ? }15 ? ? ? ? ? } else {16 ? ? ? ? ? ? ? ?errorCode = -2;17 ? ? ? ? ? }18 ? ? ? } else {19 ? ? ? ? ? ?errorCode = -3;20 ? ? ? }21 ? ? ? ?close the file;22 ? ? ? ?if (theFileDidntClose && errorCode == 0) {23 ? ? ? ? ? ?errorCode = -4;24 ? ? ? } else {25 ? ? ? ? ? ?errorCode = errorCode and -4;26 ? ? ? }27 ? } else {28 ? ? ? ?errorCode = -5;29 ? }30 ? ?return errorCode;31}
如此我們得到的是混亂糟糕的代碼，可讀性極差，將來一旦出現(xiàn)需要維護(hù)的情況，更是苦不堪言。而當(dāng)我們使用異常機(jī)制來處理時(shí)，清晰的處理邏輯和代碼可讀性不言而喻：readFile {try {open the file;determine its size;allocate that much memory;read the file into memory;close the file;} catch (fileOpenFailed) {doSomething;} catch (sizeDeterminationFailed) {doSomething;} catch (memoryAllocationFailed) {doSomething;} catch (readFailed) {doSomething;} catch (fileCloseFailed) {doSomething;} }191readFile {2 ? ?try {3 ? ? ? ?open the file;4 ? ? ? ?determine its size;5 ? ? ? ?allocate that much memory;6 ? ? ? ?read the file into memory;7 ? ? ? ?close the file;8 ? } catch (fileOpenFailed) {9 ? ? ?doSomething;10 ? } catch (sizeDeterminationFailed) {11 ? ? ? ?doSomething;12 ? } catch (memoryAllocationFailed) {13 ? ? ? ?doSomething;14 ? } catch (readFailed) {15 ? ? ? ?doSomething;16 ? } catch (fileCloseFailed) {17 ? ? ? ?doSomething;18 ? }19}
（筆者：如上例所有核心代碼都用try包裹，確實(shí)代碼清晰；而事實(shí)上倡導(dǎo)的是盡量減小try塊，我個(gè)人在寫一些涉及到IO的方法時(shí)，代碼經(jīng)常因?yàn)檫@個(gè)原則被try-catch分割得七零八落，基本上和使用if-else無差，所以個(gè)人認(rèn)為try塊對于代碼的粒度控制，不必完全基于盡量最小的原則，畢竟同時(shí)try-catch的性能影響微乎其微）

1.2 延遲處理

throws關(guān)鍵字的使用，使得可能出現(xiàn)的錯(cuò)誤不必在當(dāng)前邏輯中立即處理，而是留待給它的調(diào)用者來處理。
因?yàn)楹芏鄷r(shí)候，某些底層方法是不知道要如何去處理這些錯(cuò)誤的，而只有業(yè)務(wù)層根據(jù)實(shí)際的業(yè)務(wù)邏輯和需求，才知道如何處理，比如業(yè)務(wù)層可能會(huì)將錯(cuò)誤信息顯示給用戶，以起提示和引導(dǎo)操作。
實(shí)際上，也可以選擇層層拋出的方式，即“ catch語句中處理異常后，再次throw拋出該異常 ”，繼續(xù)拋出異?？墒沟谜{(diào)用方法能夠再次獲得并處理異常。比如程序員可以在底層方法中抓到異常后，打印錯(cuò)誤日志以供開發(fā)者查看，同時(shí)再次拋出給上層調(diào)用者，以便業(yè)務(wù)層調(diào)用時(shí)使用，如顯示錯(cuò)誤信息給用戶。
同時(shí)，受檢類型的異常也起到了提醒的作用，告知調(diào)用者這個(gè)方法可能發(fā)生異常，那么你必須進(jìn)行捕獲并考慮處理。

1.3 異常的精確定位

com.test9.MyException: 文件沒有找到--02at com.test9.Test.g(Test.java:31)at com.test9.Test.main(Test.java:38) Caused by: com.test9.MyException: 文件沒有找到--01at com.test9.Test.f(Test.java:22)at com.test9.Test.g(Test.java:28)... 1 more Caused by: java.io.FileNotFoundException: G:\myfile\struts.txt (系統(tǒng)找不到指定的路徑。)at java.io.FileInputStream.open(Native Method)at java.io.FileInputStream.<init>(FileInputStream.java:106)at java.io.FileInputStream.<init>(FileInputStream.java:66)at java.io.FileReader.<init>(FileReader.java:41)at com.test9.Test.f(Test.java:17)... 2 more1com.test9.MyException: 文件沒有找到--022 ? ?at com.test9.Test.g(Test.java:31)3 ? ?at com.test9.Test.main(Test.java:38)4Caused by: com.test9.MyException: 文件沒有找到--015 ? ?at com.test9.Test.f(Test.java:22)6 ? ?at com.test9.Test.g(Test.java:28)7 ? ... 1 more8Caused by: java.io.FileNotFoundException: G:\myfile\struts.txt (系統(tǒng)找不到指定的路徑。)9 ? ?at java.io.FileInputStream.open(Native Method)10 ? ?at java.io.FileInputStream.<init>(FileInputStream.java:106)11 ? ?at java.io.FileInputStream.<init>(FileInputStream.java:66)12 ? ?at java.io.FileReader.<init>(FileReader.java:41)13 ? ?at com.test9.Test.f(Test.java:17)14 ? ... 2 more
如果采用 if-else-print 的方式在控制臺(tái)打印錯(cuò)誤信息，以達(dá)到出錯(cuò)時(shí)提示的目的，那么在debug時(shí)無疑是不如異常機(jī)制的，如上圖例可以看到，使用異常機(jī)制，一旦出現(xiàn)異常，控制臺(tái)不光有提示，更精確定位了出錯(cuò)的代碼位置。
編程5分鐘，找蟲2小時(shí)，善用異常機(jī)制能夠節(jié)約不少調(diào)試的時(shí)間。

2、異常使用的注意事項(xiàng)

• 異常捕獲后不做任何處理，就是耍流氓，挖坑埋自己
• 異常機(jī)制不要用來做流程或條件控制，因?yàn)樘幚硇瘦^低
• try-catch若不觸發(fā)catch是不影響性能的，但是try塊仍然不要濫用包裹大量代碼 （詳見參考鏈接中相關(guān)文章）
• 方法出錯(cuò)該拋異常就拋異常，而不是返回一些錯(cuò)誤碼

3、參考鏈接

• 使用異常的優(yōu)勢
• 如何正確使用Java異常處理機(jī)制
• 淺析Java異常機(jī)制
• Java上的try catch并不影響性能
• Java程序猿必須懂的一些異常處理指引

4、異常方面的教訓(xùn)記錄

4.1 關(guān)于try-catch和自定義Exception

因?yàn)橹纓ry塊不觸發(fā)異常并不影響性能，于是我個(gè)人為了代碼更好的可讀性，擴(kuò)大了try塊的范圍。后來便給自己造成了一點(diǎn)麻煩的事就是，假如：A底層方法拋出異常，B調(diào)用A時(shí)會(huì)捕獲異常并打印信息，然后再次拋出該異常以供調(diào)用者使用。
于是我在調(diào)用B時(shí)要求處理異常，為了便于異常信息的使用，我到B的代碼中去看是哪里拋出的異常，結(jié)果try塊太龐大幾乎包裹了所有代碼，以至于我無法判斷真正拋出異常的A在B中代碼的哪個(gè)部分。所以try塊也不能濫用。
另外，自定義異常的范圍不明確，這才以至于我需要追蹤到底層去判斷捕獲的異常如何處理，是內(nèi)部記錄還是做彈窗給用戶提示？所以自定義異常的命名和創(chuàng)建也是需要明確范圍和目的，是哪種類型的業(yè)務(wù)就建相應(yīng)的異常，而不要一股腦就單獨(dú)一個(gè)BusinessException。

轉(zhuǎn)載于:https://www.cnblogs.com/deng-cc/p/7462539.html

總結(jié)

以上是生活随笔為你收集整理的[03] 为什么要使用异常机制的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。