Kotlin中的Checked Exception機制淺析

前言

現在使用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就是把異常類型進一步進行了簡化，將所有異常都歸為了不受檢查異常，僅此而已。

結論

所以，最終的結論是什么呢？

很遺憾，沒有結論。正如任何事物都有其多樣性一樣，關于Checked Exception這個問題上面，也沒有一個統一的定論。

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

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

總結

到此這篇關于Kotlin中的Checked Exception機制淺析的文章就介紹到這了,更多相關Kotlin的Checked Exception機制內容請搜索億速云以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持億速云！