Kotlin的Checked Exception機(jī)制的用法

本篇內(nèi)容介紹了“Kotlin的Checked Exception機(jī)制的用法”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

現(xiàn)在使用Kotlin的Android開發(fā)者已經(jīng)越來越多了。

這門語言從一開始的無人問津，到后來成為Android開發(fā)的一級(jí)語言，再到后來Google官宣的Kotlin  First。Kotlin正在被越來越多的開發(fā)者接受和認(rèn)可。

許多學(xué)習(xí)Kotlin的開發(fā)者之前都是學(xué)習(xí)過Java的，并且本身Kotlin就是一款基于JVM語言，因此不可避免地需要經(jīng)常和Java進(jìn)行比較。

Kotlin的諸多特性，在熟悉Java的開發(fā)者看來，有些人很喜歡，有些人不喜歡。但即使是不喜歡的那些人，一旦用熟了Kotlin進(jìn)行程序開發(fā)之后，也難逃真香定律。

今天我想跟大家聊一聊的話題，是Kotlin在早期的時(shí)候爭議比較大的一個(gè)特性：Checked Exception機(jī)制。

由于Kotlin取消了Checked  Exception，這在很多Java開發(fā)者看來是完全不可接受的，可能也是許多Java支持者拒絕使用Kotlin的原因。但目前Kotlin已經(jīng)被Google轉(zhuǎn)正兩年多了，開發(fā)了成千上萬的Android應(yīng)用。你會(huì)發(fā)現(xiàn)，即使沒有Checked  Exception，Kotlin編寫出的程序也并沒有出現(xiàn)比Java更多的問題，因此編程語言中對(duì)于Checked  Exception的必要性可能并沒有許多人想象中的那么高。

當(dāng)然，本篇文章中我并不能給出一個(gè)結(jié)論來證明誰對(duì)誰錯(cuò)，更多的是跟大家談一談我自己的觀點(diǎn)和個(gè)人心得，另外引用一些大佬的權(quán)威觀點(diǎn)。

另外，這個(gè)問題永遠(yuǎn)是沒有正確答案的，因?yàn)槭澜缟蠜]有最好的編程語言(PHP除外)。每個(gè)編程語言選擇不同的處理方式都有著自己的一套理論和邏輯，所以與其去爭論Java中的Checked  Exception機(jī)制是不是多余的，不如去論證Kotlin中沒有Checked Exception機(jī)制為什么是合理的。

那么，我們首先從什么是Checked Exception開始說起。

/ 什么是Checked Exception? /

Checked Exception，簡稱CE。它是編程語言為了保證程序能夠更好的處理和捕獲異常而引入的一種機(jī)制。

具體而言，就是當(dāng)一個(gè)方法調(diào)用了另外一個(gè)可能會(huì)拋出異常的接口時(shí)，要么將這個(gè)異常進(jìn)行捕獲，要么將這個(gè)異常拋出，交給上一層進(jìn)行捕獲。

熟悉Java語言的朋友對(duì)這一機(jī)制一定不會(huì)陌生，因?yàn)槲覀儙缀趺刻於荚谶@個(gè)機(jī)制的影響下編寫程序。

觀察如下代碼：

public void readFromFile(File file) {     FileInputStream in = null;     BufferedReader reader = null;     StringBuilder content = new StringBuilder();     try {         in = new FileInputStream(file);         reader = new BufferedReader(new InputStreamReader(in));         String line = "";         while ((line = reader.readLine()) != null) {             content.append(line);         }     } catch (IOException e) {         e.printStackTrace();     } finally {         if (reader != null) {             try {                 reader.close();             } catch (IOException e) {                 e.printStackTrace();             }         }     } }

這段代碼每位Java程序員應(yīng)該都非常熟悉，這是一段Java文件流操作的代碼。

我們?cè)谶M(jìn)行文件流操作時(shí)有各種各樣潛在的異?？赡軙?huì)發(fā)生，因此這些異常必須被捕獲或者拋出，否則程序?qū)o法編譯通過，這就是Java的Checked  Exception機(jī)制。

有了Checked  Exception，就可以保證我們的程序不會(huì)存在一些隱藏很深的潛在異常，不然的話，這些異常會(huì)像定時(shí)炸彈一樣，隨時(shí)可能會(huì)引爆我們的程序。

由此看來，Checked Exception是一種非常有必要的機(jī)制。

/ 為什么Kotlin中沒有CE? /

Kotlin中是沒有Checked  Exception機(jī)制的，這意味著我們使用Kotlin進(jìn)行上述文件流操作時(shí)，即使不捕獲或者拋出異常，也可以正常編譯通過。

熟悉Java的開發(fā)者們是不是覺得這樣嚴(yán)重沒有安全感?

那么我們就來嘗試分析和思考一下，為什么Kotlin中沒有Checked Exception。

我在學(xué)習(xí)Kotlin時(shí)，發(fā)現(xiàn)這門語言在很多設(shè)計(jì)方面都參考了一些業(yè)內(nèi)的最佳編程實(shí)踐。

舉個(gè)例子，《Effective  Java》這本書中有提到過，如果一個(gè)類并非是專門為繼承而設(shè)計(jì)的，那么我們就應(yīng)該將它聲明成final，使其不可被繼承。

而在Kotlin當(dāng)中，一個(gè)類默認(rèn)就是不可被繼承的，除非我們主動(dòng)將它聲明成open。

類似的例子還有很多很多。

因此，Kotlin取消Checked Exception也肯定不是隨隨便便拍腦瓜決定的，而是有很多的理論依據(jù)為其支持。

比如說，《Thinking in Java》的作者 Bruce Eckel就曾經(jīng)公開表示，Java語言中的Checked  Exception是一個(gè)錯(cuò)誤的決定，Java應(yīng)該移除它。C#之父Anders Hejlsberg也認(rèn)同這個(gè)觀點(diǎn)，因此C#中是沒有Checked  Exception的。

那么我們大多數(shù)Java開發(fā)者都認(rèn)為非常有必要的Checked Exception機(jī)制到底存在什么問題呢?

這些大佬們例舉了很多方面的原因，但是我個(gè)人認(rèn)為最主要的原因其實(shí)就是一個(gè)：麻煩。

Checked Exception機(jī)制雖然提升了編程語言的安全性，但是有時(shí)卻讓我們?cè)跁鴮懘a時(shí)相當(dāng)抓狂。

由于Checked Exception機(jī)制的存在，對(duì)于一些可能發(fā)生潛在異常的代碼，我們必須要對(duì)其進(jìn)行處理才行。處理方式只有兩種：要么使用try  catch代碼塊將異常捕獲住，要么使用throws關(guān)鍵字將異常拋出。

以剛才的文件流操作舉例，我們使用了兩次try catch代碼塊來進(jìn)行潛在的異常捕獲，但其實(shí)更多只是為了能讓編譯器滿意：

public void readFromFile(File file) {     BufferedReader reader = null;     try {         ...     } catch (IOException e) {         e.printStackTrace();     } finally {         if (reader != null) {             try {                 reader.close();             } catch (IOException e) {                 e.printStackTrace();             }         }     } }

這段代碼在Java當(dāng)中是最標(biāo)準(zhǔn)和規(guī)范的寫法，然而你會(huì)發(fā)現(xiàn)，我們幾乎沒有人能在catch中寫出什么有意義的邏輯處理，通常都只是打印一下異常信息，告知流發(fā)生異常了。那么流發(fā)生異常應(yīng)該怎么辦呢?沒人知道應(yīng)該怎么辦，理論上流應(yīng)該總是能正常工作的。

思考一下，是不是你在close文件流時(shí)所加的try  catch都只是為了能夠讓編譯通過而已?你有在close的異常捕獲中進(jìn)行過什么有意義的邏輯處理嗎?

而Checked Exception機(jī)制的存在強(qiáng)制要求我們對(duì)這些未捕獲的異常進(jìn)行處理，即使我們明確不想對(duì)它進(jìn)行處理都不可以。

這種機(jī)制的設(shè)計(jì)思路本身是好的，但是卻也間接造就了很多填鴨式的代碼，只是為了滿足編譯器去編程，導(dǎo)致編寫了很多無意義的try  catch語句，讓項(xiàng)目代碼看來得變得更加臃腫。

那么如果我們選擇不對(duì)異常進(jìn)行捕獲，而是將異常向上拋出呢?事實(shí)證明，這可能也并不是什么特別好的主意。

絕大多數(shù)Java程序員應(yīng)該都使用過反射的API，編寫反射代碼時(shí)有一點(diǎn)特別討厭，就是它的API會(huì)拋出一大堆的異常：

Object reflect(Object object, String className, String methodName, Object[] parameters, Class<?>[] parameterTypes)         throws SecurityException, IllegalArgumentException,          IllegalAccessException, InvocationTargetException,          NoSuchMethodException, ClassNotFoundException {     Class<?> objectClass = Class.forName(className);     Method method = objectClass.getMethod(methodName, parameterTypes);     return method.invoke(object, parameters); }

這里我只是編寫了一段最簡單的反射代碼，竟然有6個(gè)異常要等著我去處理。其中每個(gè)異常代表什么意思我也沒能完全搞明白，與其我自己去寫一大堆的try  catch代碼，還不如直接將所有異常都拋出到上一層得了，這樣代碼看起來還能清爽一點(diǎn)。

你是這么想的，上一層的人也是這么想的，更過分的是，他可能還會(huì)在你拋出異常的基礎(chǔ)之上，再增加一點(diǎn)其他的異常繼續(xù)往上拋出。

根據(jù)我查閱到的資料，有些項(xiàng)目經(jīng)過這樣的層層累加之后，調(diào)用一個(gè)接口甚至需要捕獲80多個(gè)異常。想必調(diào)用這個(gè)接口的人心里一定在罵娘吧。你覺得在這種情況下，他還能耐心地對(duì)每一種異常類型都細(xì)心進(jìn)行處理嗎?絕對(duì)不可能，大概率可能他只會(huì)catch一個(gè)頂層的Exception，把所有異常都囊括進(jìn)去，從而徹底地讓Checked  Exception機(jī)制失去意義。又或者，他可能會(huì)在當(dāng)前異常拋出鏈上再加一把火，為拋出100個(gè)異常做出貢獻(xiàn)。。。

最終我們可以看出，Java的Checked  Exception機(jī)制，本身的設(shè)計(jì)初衷確實(shí)是好的，而且是先進(jìn)的，但是卻對(duì)程序員有著較高的編碼規(guī)范要求。每一層方法的設(shè)計(jì)者都應(yīng)該能清楚地辨別哪些異常是應(yīng)該自己內(nèi)部捕獲的，哪些異常是應(yīng)該向上拋出的，從而讓整個(gè)方法調(diào)用棧的異常鏈都在一個(gè)合理和可控的范圍內(nèi)。

然而比較遺憾的現(xiàn)實(shí)是，絕大多數(shù)的程序員其實(shí)都是做不到這一點(diǎn)的，濫用和惰性使用CE機(jī)制的情況廣泛存在，完全達(dá)不到Java本身設(shè)計(jì)這個(gè)機(jī)制所預(yù)期的效果，這也是Kotlin取消Checked  Exception的原因。

/ 沒有CE不會(huì)出現(xiàn)問題嗎? /

許多Java程序員會(huì)比較擔(dān)心這一點(diǎn)，Kotlin取消了Checked  Exception機(jī)制，這樣不會(huì)導(dǎo)致我的程序變得很危險(xiǎn)嗎?每當(dāng)我調(diào)用一個(gè)方法時(shí)，都完全不知道這個(gè)方法可能會(huì)拋出什么異常。

首先這個(gè)問題在開頭已經(jīng)給出了答案，經(jīng)過兩年多的實(shí)踐發(fā)現(xiàn)，即使沒有Checked  Exception，Kotlin開發(fā)出的程序也并沒有比Java開發(fā)的程序出現(xiàn)更多的異常。恰恰相反，Kotlin程序反倒是減少了很多異常，因?yàn)镵otlin增加了編譯期處理空指針異常的功能(空指針在各類語言的崩潰率排行榜中都一直排在第一位)。

那么至于為什么取消Checked Exception并不會(huì)成為導(dǎo)致程序出現(xiàn)更多異常的原因，我想分成以下幾個(gè)點(diǎn)討論。

第一，Kotlin并沒有阻止你去捕獲潛在的異常，只是不強(qiáng)制要求你去捕獲而已。

經(jīng)驗(yàn)豐富的程序員在編寫程序時(shí)，哪些地方最有可能發(fā)生異常其實(shí)大多是心中有數(shù)的。比如我正在編寫網(wǎng)絡(luò)請(qǐng)求代碼，由于網(wǎng)絡(luò)存在不穩(wěn)定性，請(qǐng)求失敗是極有可能發(fā)生的事情，所以即使沒有Checked  Exception，大多數(shù)程序員也都知道應(yīng)該在這里加上一個(gè)try catch，防止因?yàn)榫W(wǎng)絡(luò)請(qǐng)求失敗導(dǎo)致程序崩潰。

另外，當(dāng)你不確定調(diào)用一個(gè)方法會(huì)不會(huì)有潛在的異常拋出時(shí)，你永遠(yuǎn)可以通過打開這個(gè)方法，觀察它的拋出聲明來進(jìn)行確定。不管你有沒有這個(gè)類的源碼都可以看到它的每個(gè)方法拋出了哪些異常：

public class FileInputStream extends InputStream {      public FileInputStream(File file) throws FileNotFoundException {         throw new RuntimeException("Stub!");     }      public int read(byte[] b, int off, int len) throws IOException {         throw new RuntimeException("Stub!");     }      public void close() throws IOException {         throw new RuntimeException("Stub!");     }     ... }

然后當(dāng)你覺得需要對(duì)這個(gè)異常進(jìn)行捕獲時(shí)，再對(duì)它進(jìn)行捕獲即可，相當(dāng)于你仍然可以按照之前在Java中捕獲異常的方式去編寫Kotlin代碼，只是沒有了強(qiáng)制的要求，你可以自由選擇要不要進(jìn)行捕獲和拋出。

第二，絕大多數(shù)的方法其實(shí)都是沒有拋出異常的。

這是一個(gè)事實(shí)，不然你絕對(duì)不會(huì)愛上Checked Exception機(jī)制，而是會(huì)天天咒罵它。

試想一下，假如你編寫的每一行代碼，調(diào)用的每一個(gè)方法，都必須要對(duì)它try catch捕獲一下才行，你是不是想摔鍵盤的心都有了?

我說的這種情況在Java中真的有一個(gè)非常典型的例子，就是Thread.sleep()方法。由于Thread.sleep()方法會(huì)拋出一個(gè)InterruptedException，所以每次我們調(diào)用這個(gè)方法時(shí)，都必須要用try  catch捕獲一下：

public class Main {      public void test() {         // do something before         try {             Thread.sleep(1000);         } catch (InterruptedException e) {             e.printStackTrace();         }         // do something after     }  }

這也是我極其不喜歡這個(gè)方法的原因，用起來就是一個(gè)字：煩。

事實(shí)上，可能絕大多數(shù)Java程序員甚至都不知道為什么要捕獲這個(gè)異常，只知道編譯器提醒我必須捕獲。

之所以我們?cè)谡{(diào)用Thread.sleep()方法時(shí)需要捕獲InterruptedException，是因?yàn)槿绻诋?dāng)前線程睡眠的過程中，我們?cè)诹硗庖粋€(gè)線程對(duì)中這個(gè)睡眠中的線程進(jìn)行中斷(調(diào)用thrad.interrupt()方法)，那么sleep()方法會(huì)結(jié)束休眠，并拋出一個(gè)InterruptedException。這種操作是非常少見的，但是由于Checked  Exception的存在，我們每個(gè)人都需要為這一個(gè)少見的操作買單：即每次調(diào)用Thread.sleep()方法時(shí)，都要寫一段長長的try catch代碼。

而到了Kotlin當(dāng)中，你會(huì)不再討厭使用Thread.sleep()方法，因?yàn)闆]有了Checked Exception，代碼也變得清爽了：

class Main {      fun test() {         // do something before         Thread.sleep(1000)         // do something after     }  }

第三，擁有Checked Exception的Java也并不是那么安全。

有些人認(rèn)為，Java中擁有Checked Exception機(jī)制，調(diào)用的每個(gè)方法你都會(huì)感到放心，因?yàn)橹浪鼤?huì)拋出什么異常。而沒有Checked  Exception的話，調(diào)用任何方法心里都感覺沒底。

那么這種說法有道理嗎?顯然這不是真的。不然，你的Java程序應(yīng)該永遠(yuǎn)都不會(huì)崩潰才對(duì)。

事實(shí)上，Java將所有的異常類型分成了兩類：受檢查異常和不受檢查異常。只有受檢查異常才會(huì)受到Checked  Exception機(jī)制的約束，不受檢查異常是不會(huì)強(qiáng)制要求你對(duì)異常進(jìn)行捕獲或拋出的。

比如說，像NullPointerException、ArrayIndexOutOfBoundsException、IllegalArgumentException這些都是不受檢查的異常，所以你調(diào)用的方法中即使存在空指針、數(shù)組越界等異常風(fēng)險(xiǎn)，Checked  Exception機(jī)制也并不會(huì)要求你進(jìn)行捕獲或拋出。

由此可見，即使Java擁有Checked  Exception機(jī)制，也并不能向你保證你調(diào)用的每個(gè)方法都是安全的，而且我認(rèn)為空指針和數(shù)組越界等異常要遠(yuǎn)比InterruptedException之類的異常更加常見，但Java并沒有對(duì)此進(jìn)行保護(hù)。

至于Java是如何劃分哪些異常屬于受檢查異常，哪些屬于不受檢查異常，這個(gè)我也不太清楚。Java的設(shè)計(jì)團(tuán)隊(duì)一定有自己的一套理論依據(jù)，只不過這套理論依據(jù)看上去并沒有被其他語言的設(shè)計(jì)者所認(rèn)可。

因此，你大概可以理解成，Kotlin就是把異常類型進(jìn)一步進(jìn)行了簡化，將所有異常都?xì)w為了不受檢查異常，僅此而已。

/ 結(jié)論 /

所以，最終的結(jié)論是什么呢?

很遺憾，沒有結(jié)論。正如任何事物都有其多樣性一樣，關(guān)于Checked Exception這個(gè)問題上面，也沒有一個(gè)統(tǒng)一的定論。

Java擁有Checked Exception機(jī)制并不是錯(cuò)誤的，Kotlin中取消Checked  Exception機(jī)制也不是錯(cuò)誤的。我想這大概就是你閱讀完本文之后能夠得出的結(jié)論吧。

但是，希望你自此往后，在使用Kotlin編程程序時(shí)，不要再為有沒有Checked Exception的問題所糾結(jié)了。

“Kotlin的Checked Exception機(jī)制的用法”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！