浅谈Kotlin的Checked-Exception机制，2024最新Android中级面试题目汇总解答

本文链接：https://blog.csdn.net/2301_78398209/article/details/137204891

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代码，还不如直接将所有异常都抛出到上一层得了，这样代码看起来还能清爽一点。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。