但4G模块应用数据仍在上涨

这段代码在Java当中是最标准和规范的写法，然而你会发现，我们几乎没有人能在catch中写出什么有意义的逻辑处理，通常都只是打印一下异常信息，告知流发生异常了。那么流发生异常应该怎么办呢?没人知道应该怎么办，理论上流应该总是能正常工作的。

思考一下，是不是你在close文件流时所加的try catch都只是为了能够让编译通过而已?你有在close的异常捕获中进行过什么有意义的逻辑处理吗?

而Checked Exception机制的存在强制要求我们对这些未捕获的异常进行处理，即使我们明确不想对它进行处理都不可以。

这种机制的设计思路本身是好的，但是却也间接造就了很多填鸭式的代码，只是为了满足编译器去编程，导致编写了很多无意义的try catch语句，让项目代码看来得变得更加臃肿。

那么如果我们选择不对异常进行捕获，而是将异常向上抛出呢?事实证明，这可能也并不是什么特别好的主意。

绝大多数Java程序员应该都使用过反射的API，编写反射代码时有一点特别讨厌，就是它的API会抛出一大堆的异常：
 

这段代码每位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代码块来进行潜在的异常捕获，但其实更多只是为了能让编译器满意：

（编辑：烟台站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!