前言

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

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

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

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

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

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

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

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

那么，我們首先從什么是Checked Exception開(kāi)始說(shuō)起。

什么是Checked Exception？

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

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

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

觀察如下代碼：

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(wú)法編譯通過(guò)，這就是Java的Checked Exception機(jī)制。

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

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

為什么Kotlin中沒(méi)有CE？

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

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

那么我們就來(lái)嘗試分析和思考一下，為什么Kotlin中沒(méi)有Checked Exception。

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

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

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

類(lèi)似的例子還有很多很多。

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

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

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

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

Checked Exception機(jī)制雖然提升了編程語(yǔ)言的安全性，但是有時(shí)卻讓我們?cè)跁?shū)寫(xiě)代碼時(shí)相當(dāng)抓狂。

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

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

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ī)范的寫(xiě)法，然而你會(huì)發(fā)現(xiàn)，我們幾乎沒(méi)有人能在catch中寫(xiě)出什么有意義的邏輯處理，通常都只是打印一下異常信息，告知流發(fā)生異常了。那么流發(fā)生異常應(yīng)該怎么辦呢？沒(méi)人知道應(yīng)該怎么辦，理論上流應(yīng)該總是能正常工作的。

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

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

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

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

絕大多數(shù)Java程序員應(yīng)該都使用過(guò)反射的API，編寫(xiě)反射代碼時(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);
}

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

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

根據(jù)我查閱到的資料，有些項(xiàng)目經(jīng)過(guò)這樣的層層累加之后，調(diào)用一個(gè)接口甚至需要捕獲80多個(gè)異常。想必調(diào)用這個(gè)接口的人心里一定在罵娘吧。你覺(jué)得在這種情況下，他還能耐心地對(duì)每一種異常類(lèi)型都細(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的原因。

沒(méi)有CE不會(huì)出現(xiàn)問(wè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è)問(wèn)題在開(kāi)頭已經(jīng)給出了答案，經(jīng)過(guò)兩年多的實(shí)踐發(fā)現(xiàn)，即使沒(méi)有Checked Exception，Kotlin開(kāi)發(fā)出的程序也并沒(méi)有比Java開(kāi)發(fā)的程序出現(xiàn)更多的異常。恰恰相反，Kotlin程序反倒是減少了很多異常，因?yàn)镵otlin增加了編譯期處理空指針異常的功能（空指針在各類(lèi)語(yǔ)言的崩潰率排行榜中都一直排在第一位）。

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

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

經(jīng)驗(yàn)豐富的程序員在編寫(xiě)程序時(shí)，哪些地方最有可能發(fā)生異常其實(shí)大多是心中有數(shù)的。比如我正在編寫(xiě)網(wǎng)絡(luò)請(qǐng)求代碼，由于網(wǎng)絡(luò)存在不穩(wěn)定性，請(qǐng)求失敗是極有可能發(fā)生的事情，所以即使沒(méi)有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)可以通過(guò)打開(kāi)這個(gè)方法，觀察它的拋出聲明來(lái)進(jìn)行確定。不管你有沒(méi)有這個(gè)類(lèi)的源碼都可以看到它的每個(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)你覺(jué)得需要對(duì)這個(gè)異常進(jìn)行捕獲時(shí)，再對(duì)它進(jìn)行捕獲即可，相當(dāng)于你仍然可以按照之前在Java中捕獲異常的方式去編寫(xiě)Kotlin代碼，只是沒(méi)有了強(qiáng)制的要求，你可以自由選擇要不要進(jìn)行捕獲和拋出。

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

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

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

我說(shuō)的這種情況在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è)方法的原因，用起來(lái)就是一個(gè)字：煩。

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

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

而到了Kotlin當(dāng)中，你會(huì)不再討厭使用Thread.sleep()方法，因?yàn)闆](méi)有了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ì)拋出什么異常。而沒(méi)有Checked Exception的話(huà)，調(diào)用任何方法心里都感覺(jué)沒(méi)底。

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

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

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

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

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

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

結(jié)論

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

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

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

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

總結(jié)

到此這篇關(guān)于Kotlin中的Checked Exception機(jī)制淺析的文章就介紹到這了,更多相關(guān)Kotlin的Checked Exception機(jī)制內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！