Versions:2009-01-01 2017-05-24 2017-05-31 2017-10-22 2017-11-21 2017-12-16 2018-02-24 2019-10-19 2019-11-18 2020-02-17 2024-03-21

Kotlin 和 Checked Exception

最近 JetBrains 的 Kotlin 语言忽然成了热门话题。国内小编们传言说,Kotlin 成为了 Android 的“钦定语言”,很多人听了之后热血沸腾。初学者们也开始注意到 Kotlin,问出各种“傻问题”,很“功利”的问题,比如“现在学 Kotlin 是不是太早了一点?” 结果引起一些 Kotlin 老鸟们的鄙视。当然也有人来信,请求我评价 Kotlin。

对于这种评价语言的请求,我一般都不予理睬的。作为一个专业的语言研究者,我的职责不应该是去评价别人设计的语言。然而浏览了 Kotlin 的文档之后,我发现 Kotlin 的设计者误解了一个重要的问题——关于是否需要 checked exception。对于这个话题我已经憋了很久,觉得有必要分享一下我对此的看法,避免误解的传播,所以我还是决定写一篇文章。

可以说我这篇文章针对的是 checked exception,而不是 Kotlin,因为同样的问题也存在于 C# 和其它一些语言。

冷静一下

在进入主题之前,我想先纠正一些人的误解,让他们先冷静下来。我们首先应该搞清楚的是,Kotlin 并不是像有些小编传言的那样,要取代 Java 成为 Android 的“官方语言”。准确的说,Kotlin 只是得到了 Android 的“官方支持”,所以你可以用 Kotlin 顺利地开发 Android 程序,而不需要绕过很多限制。

Android 显然不可能抛弃 Java 而拥抱 Kotlin。毕竟现有的 Android 代码绝大部分都是 Java 写的,绝大部分程序员都在用 Java。很多人都知道 Java 的好处,所以他们不会愿意换用一个新的,未经时间考验的语言。所以虽然 Kotlin 在 Android 上得到了和 Java 平起平坐的地位,想要程序员们从 Java 转到 Kotlin,却不是一件容易的事情。

我不明白为什么每当出现一个 JVM 的语言,就有人欢呼雀跃的,希望它会取代 Java,似乎这些人跟 Java 有什么深仇大恨。他们已经为很多新语言热血沸腾过了,不是吗?这里面包括了红极一时,但很快衰落了的 Scala 和 Clojure…… Kotlin 的主页也把“drastically reduce the amount of boilerplate code”作为了自己的一大特色,仿佛是在暗示大家 Java 有很多“boilerplate code”。

如果你真的理解编程的精髓,就会发现 Java 并不是那么的讨厌。正好相反,Java 的有些设计看起来“繁复多余”,实际上却是经过深思熟虑的好设计。Java 的设计者有时候知道有些东西可以简化,却故意把它做成多余的。不理解语言“可用性”的人,往往以为简短就是好,却忽视了很多实际的问题。关于 Java 的良好设计,你可以参考我之前的文章《为 Java 说句公道话》。另外在《对 Rust 语言的分析》里面,我也提到一些容易被误解的“语言可用性”问题。我希望这些文章对人们有所帮助,避免他们因为头脑发热而扔掉好的东西。

实际上我很早以前就发现了 Kotlin,看过它的文档,当时并没有引起我很大的兴趣。现在它忽然火了起来,我再次浏览它的新版文档,却发现自己还是会继续使用 Java 或者 C++。虽然我觉得 Kotlin 比起 Java 在某些小地方设计相对优雅,一致性稍好一些,然而我并没有发现它可以让我兴奋到愿意丢掉 Java 的地步。实际上 Kotlin 的好些小改进,我在设计自己语言的时候都已经想到了,然而我并不觉得它们可以成为人们换用一个新语言的理由。

Checked Exception(CE)的重要性

有几个我觉得很重要的,具有突破性的语言特性,Kotlin 并没有实现。另外我还发现一个很重要的 Java 特性,被 Kotlin 的设计者给盲目抛弃了。这就是我今天要讲的主题:checked exception。我不知道这个术语有什么标准的中文翻译,为了避免引起定义混乱,下文我就把它简称为“CE”好了。

Kotlin 的文档明确说明它不支持类似 Java 的 checked exception(CE),指出了 CE 的缺点是“繁琐”,并且列举了几个普通程序员眼中“大牛”的文章,想以此来证明为什么 Java 的 CE 是一个错误,为什么它不解决问题,却带来了麻烦。这些大牛包括了 Bruce Eckel 和 C# 的设计者 Anders Hejlsberg

很早的时候我就看过 Hejlsberg 的这些言论。他的话看似有道理,然而通过自己编程和设计语言的实际经验,我发现他并没有抓住问题的关键。他的论述里有好几处逻辑错误,一些自相矛盾,还有一些盲目的臆断,所以这些言论并没能说服我。正好相反,实在的项目经验告诉我,CE 是 C# 缺少的一项重要特性,没有了 CE 会带来相当麻烦的后果。在微软写 C# 的时候,我已经深刻体会到了缺少 CE 所带来的困扰。

现在我就来讲一下,CE 为什么是很重要的语言特性,然后讲一下为什么 Hejlsberg 对它的批评是站不住脚的。

首先,写 C# 代码时最让我头痛的事情之一,就是 C# 没有 CE。每调用一个函数(不管是标准库函数,第三方库函数,还是队友写的函数,甚至我自己写的函数),我都会疑惑这个函数是否会抛出异常。由于 C# 的函数类型上没有 throws 标记它可能抛出的异常,为了确保一个函数不会抛出异常,你就需要检查这个函数的源代码,以及它调用的那些函数的源代码……

也就是说,你必须检查这个函数的整个“调用树”的代码,才能确信这个函数不会抛出异常。这样的调用树可以是非常大的。说白了,这就是在用人工对代码进行“全局静态分析”,遍历整个调用树。这不但费时费力,看得你眼花缭乱,还容易漏掉出错。显然让人做这种事情是不现实的,所以绝大部分时候,程序员都不能确信这个函数调用不会出现异常。

在这种疑虑的情况下,你就不得不做最坏的打算,你就得把代码写成:

try
{
    foo();
} 
catch (Exception)
{
    ...
}