本文同步發表于我的微信公眾號，掃一掃文章底部的二維碼或在微信搜索郭霖即可關注，每個作業日都有文章更新，

現在使用Kotlin的Android開發者已經越來越多了，

這門語言從一開始的無人問津，到后來成為Android開發的一級語言，再到后來Google官宣的Kotlin First，Kotlin正在被越來越多的開發者接受和認可，

許多學習Kotlin的開發者之前都是學習過Java的，并且本身Kotlin就是一款基于JVM語言，因此不可避免地需要經常和Java進行比較，

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

今天我想跟大家聊一聊的話題，是Kotlin在早期的時候爭議比較大的一個特性：Checked Exception機制，

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

當然，本篇文章中我并不能給出一個結論來證明誰對誰錯，更多的是跟大家談一談我自己的觀點和個人心得，另外參考一些大佬的權威觀點，

另外，這個問題永遠是沒有正確答案的，因為世界上沒有最好的編程語言（PHP除外），每個編程語言選擇不同的處理方式都有著自己的一套理論和邏輯，所以與其去爭論Java中的Checked Exception機制是不是多余的，不如去論證Kotlin中沒有Checked Exception機制為什么是合理的，

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

什么是Checked Exception？

Checked Exception，簡稱CE，它是編程語言為了保證程式能夠更好的處理和捕獲例外而引入的一種機制，

具體而言，就是當一個方法呼叫了另外一個可能會拋出例外的介面時，要么將這個例外進行捕獲，要么將這個例外拋出，交給上一層進行捕獲，

熟悉Java語言的朋友對這一機制一定不會陌生，因為我們幾乎每天都在這個機制的影響下撰寫程式，

觀察如下代碼：

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程式員應該都非常熟悉，這是一段Java檔案流操作的代碼，

我們在進行檔案流操作時有各種各樣潛在的例外可能會發生，因此這些例外必須被捕獲或者拋出，否則程式將無法編譯通過，這就是Java的Checked Exception機制，

有了Checked Exception，就可以保證我們的程式不會存在一些隱藏很深的潛在例外，不然的話，這些例外會像定時炸彈一樣，隨時可能會引爆我們的程式，

由此看來，Checked Exception是一種非常有必要的機制，

為什么Kotlin中沒有CE？

Kotlin中是沒有Checked Exception機制的，這意味著我們使用Kotlin進行上述檔案流操作時，即使不捕獲或者拋出例外，也可以正常編譯通過，

熟悉Java的開發者們是不是覺得這樣嚴重沒有安全感？

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

我在學習Kotlin時，發現這門語言在很多設計方面都參考了一些業內的最佳編程實踐，

舉個例子，《Effective Java》這本書中有提到過，如果一個類并非是專門為繼承而設計的，那么我們就應該將它宣告成final，使其不可被繼承，

而在Kotlin當中，一個類默認就是不可被繼承的，除非我們主動將它宣告成open，

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

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

比如說，《Thinking in Java》的作者 Bruce Eckel就曾經公開表示，Java語言中的Checked Exception是一個錯誤的決定，Java應該移除它，C#之父Anders Hejlsberg也認同這個觀點，因此C#中是沒有Checked Exception的，

那么我們大多數Java開發者都認為非常有必要的Checked Exception機制到底存在什么問題呢？

這些大佬們例舉了很多方面的原因，但是我個人認為最主要的原因其實就是一個：麻煩，

Checked Exception機制雖然提升了編程語言的安全性，但是有時卻讓我們在書寫代碼時相當抓狂，

由于Checked Exception機制的存在，對于一些可能發生潛在例外的代碼，我們必須要對其進行處理才行，處理方式只有兩種：要么使用try catch代碼塊將例外捕獲住，要么使用throws關鍵字將例外拋出，

以剛才的檔案流操作舉例，我們使用了兩次try catch代碼塊來進行潛在的例外捕獲，但其實更多只是為了能讓編譯器滿意：

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當中是最標準和規范的寫法，然而你會發現，我們幾乎沒有人能在catch中寫出什么有意義的邏輯處理，通常都只是列印一下例外資訊，告知流發生例外了，那么流發生例外應該怎么辦呢？沒人知道應該怎么辦，理論上流應該總是能正常作業的，

思考一下，是不是你在close檔案流時所加的try catch都只是為了能夠讓編譯通過而已？你有在close的例外捕獲中進行過什么有意義的邏輯處理嗎？

而Checked Exception機制的存在強制要求我們對這些未捕獲的例外進行處理，即使我們明確不想對它進行處理都不可以，

這種機制的設計思路本身是好的，但是卻也間接造就了很多填鴨式的代碼，只是為了滿足編譯器去編程，導致撰寫了很多無意義的try catch陳述句，讓專案代碼看來得變得更加臃腫，

那么如果我們選擇不對例外進行捕獲，而是將例外向上拋出呢？事實證明，這可能也并不是什么特別好的主意，

絕大多數Java程式員應該都使用過反射的API，撰寫反射代碼時有一點特別討厭，就是它的API會拋出一大堆的例外：

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個例外要等著我去處理，其中每個例外代表什么意思我也沒能完全搞明白，與其我自己去寫一大堆的try catch代碼，還不如直接將所有例外都拋出到上一層得了，這樣代碼看起來還能清爽一點，

你是這么想的，上一層的人也是這么想的，更過分的是，他可能還會在你拋出例外的基礎之上，再增加一點其他的例外繼續往上拋出，

根據我查閱到的資料，有些專案經過這樣的層層累加之后，呼叫一個介面甚至需要捕獲80多個例外，想必呼叫這個介面的人心里一定在罵娘吧，你覺得在這種情況下，他還能耐心地對每一種例外型別都細心進行處理嗎？絕對不可能，大概率可能他只會catch一個頂層的Exception，把所有例外都囊括進去，從而徹底地讓Checked Exception機制失去意義，又或者，他可能會在當前例外拋出鏈上再加一把火，為拋出100個例外做出貢獻，，，

最終我們可以看出，Java的Checked Exception機制，本身的設計初衷確實是好的，而且是先進的，但是卻對程式員有著較高的編碼規范要求，每一層方法的設計者都應該能清楚地辨別哪些例外是應該自己內部捕獲的，哪些例外是應該向上拋出的，從而讓整個方法呼叫堆疊的例外鏈都在一個合理和可控的范圍內，

然而比較遺憾的現實是，絕大多數的程式員其實都是做不到這一點的，濫用和惰性使用CE機制的情況廣泛存在，完全達不到Java本身設計這個機制所預期的效果，這也是Kotlin取消Checked Exception的原因，

沒有CE不會出現問題嗎？

許多Java程式員會比較擔心這一點，Kotlin取消了Checked Exception機制，這樣不會導致我的程式變得很危險嗎？每當我呼叫一個方法時，都完全不知道這個方法可能會拋出什么例外，

首先這個問題在開頭已經給出了答案，經過兩年多的實踐發現，即使沒有Checked Exception，Kotlin開發出的程式也并沒有比Java開發的程式出現更多的例外，恰恰相反，Kotlin程式反倒是減少了很多例外，因為Kotlin增加了編譯期處理空指標例外的功能（空指標在各類語言的崩潰率排行榜中都一直排在第一位），

那么至于為什么取消Checked Exception并不會成為導致程式出現更多例外的原因，我想分成以下幾個點討論，

第一，Kotlin并沒有阻止你去捕獲潛在的例外，只是不強制要求你去捕獲而已，

經驗豐富的程式員在撰寫程式時，哪些地方最有可能發生例外其實大多是心中有數的，比如我正在撰寫網路請求代碼，由于網路存在不穩定性，請求失敗是極有可能發生的事情，所以即使沒有Checked Exception，大多數程式員也都知道應該在這里加上一個try catch，防止因為網路請求失敗導致程式崩潰，

另外，當你不確定呼叫一個方法會不會有潛在的例外拋出時，你永遠可以通過打開這個方法，觀察它的拋出宣告來進行確定，不管你有沒有這個類的原始碼都可以看到它的每個方法拋出了哪些例外：

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!");
    }
    ...
}

然后當你覺得需要對這個例外進行捕獲時，再對它進行捕獲即可，相當于你仍然可以按照之前在Java中捕獲例外的方式去撰寫Kotlin代碼，只是沒有了強制的要求，你可以自由選擇要不要進行捕獲和拋出，

第二，絕大多數的方法其實都是沒有拋出例外的，

這是一個事實，不然你絕對不會愛上Checked Exception機制，而是會天天咒罵它，

試想一下，假如你撰寫的每一行代碼，呼叫的每一個方法，都必須要對它try catch捕獲一下才行，你是不是想摔鍵盤的心都有了？

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

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

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

事實上，可能絕大多數Java程式員甚至都不知道為什么要捕獲這個例外，只知道編譯器提醒我必須捕獲，

之所以我們在呼叫Thread.sleep()方法時需要捕獲InterruptedException，是因為如果在當前執行緒睡眠的程序中，我們在另外一個執行緒對中這個睡眠中的執行緒進行中斷（呼叫thrad.interrupt()方法），那么sleep()方法會結束休眠，并拋出一個InterruptedException，這種操作是非常少見的，但是由于Checked Exception的存在，我們每個人都需要為這一個少見的操作買單：即每次呼叫Thread.sleep()方法時，都要寫一段長長的try catch代碼，

而到了Kotlin當中，你會不再討厭使用Thread.sleep()方法，因為沒有了Checked Exception，代碼也變得清爽了：

class Main {

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

}

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

有些人認為，Java中擁有Checked Exception機制，呼叫的每個方法你都會感到放心，因為知道它會拋出什么例外，而沒有Checked Exception的話，呼叫任何方法心里都感覺沒底，

那么這種說法有道理嗎？顯然這不是真的，不然，你的Java程式應該永遠都不會崩潰才對，

事實上，Java將所有的例外型別分成了兩類：受檢查例外和不受檢查例外，只有受檢查例外才會受到Checked Exception機制的約束，不受檢查例外是不會強制要求你對例外進行捕獲或拋出的，

比如說，像NullPointerException、ArrayIndexOutOfBoundsException、IllegalArgumentException這些都是不受檢查的例外，所以你呼叫的方法中即使存在空指標、陣列越界等例外風險，Checked Exception機制也并不會要求你進行捕獲或拋出，

由此可見，即使Java擁有Checked Exception機制，也并不能向你保證你呼叫的每個方法都是安全的，而且我認為空指標和陣列越界等例外要遠比InterruptedException之類的例外更加常見，但Java并沒有對此進行保護，

至于Java是如何劃分哪些例外屬于受檢查例外，哪些屬于不受檢查例外，這個我也不太清楚，Java的設計團隊一定有自己的一套理論依據，只不過這套理論依據看上去并沒有被其他語言的設計者所認可，

因此，你大概可以理解成，Kotlin就是把例外型別進一步進行了簡化，將所有例外都歸為了不受檢查例外，僅此而已，