Java的checked exception有意义吗？

电玩女神 2024-03-02 08:45 17阅读 0赞

### 1 前言 ###

这种异常必须在编译前就try/catch，又不一定会抛异常，小项目中不明显，大项目中，会造成不必要代码臃肿和可读性降低，完全可在编译出错时，通过单元测试和调试，得到正确代码。这设计还有啥意义？

Checked Exception初衷很好，但事实上是没啥卵用设计。

### 2 初衷很好 ###

因为我们都知软件会有各种问题，严谨处理这些问题会很好提高健壮性。Checked Exception就是让一个方法指定自己一定会抛啥异常，调用者须决定一定要处理（catch），或明确声明继续向上抛（throws）。整个程序对异常处理就很明确，程序员也有章可循，UT，测试也能明确该处理啥错误。

### 3 现实骨感 ###

若说较接近底层的系统还能相对设计出较完备严谨的异常体系，业务系统做这个严重吃力不讨好。

业务系统中，一个典型业务接口，有一个正常处理结果，但可能却有几十个不正常case。而Checked Exception要求须每层调用，要不挨个处理，要不挨个声明往上抛。

#### 挨个处理 ####

不现实，因为：

*  大部分情况下，大多数异常都是极端情况，几乎不会出现
 *  即使出现，影响也不大

如一个基金详情，底层可能调用十几个不同基金信息数据源（基本信息，经理，基金公司，费率，净值，重仓股）。如因为意外少个1、2个，最好软处理。如须使用Checked Exception，很多人会这么干：

try {
        
      Fund fund = getFund(fundCode);
    } catch (SomeNotImportantButCheckedException e) {
        
      // do nothing
    }

用IDE自动产生catch block但就不处理。或干脆：

try {
        
      Fund fund = getFund(fundCode);
    } catch (Exception e) {
        
      // do nothing
    }

这比不catch，自动往上抛更垃圾。所以一般来讲，业务系统都会有收底的错误处理，这个处理可能在业务系统最高层。大部分不需要认真处理的异常往上抛。当真意识到某问题值得仔细处理，可能才专门为它仔细设计Exception和处理。

挨个明确\[throws\]也不现实。一般看throws后边能挂3～4种Exception。按上面假设，可能要搞几十种Exception，且随层级提高，数量越堆越多。Java这一般建议用类的体系来组织这些Exception，然后throws一个合适基类。但设计一个比较好的类体系很难。更何况大多数异常都不重要，直接收底处理的。

为不重要的事耗精力不值当，于是基本都简化处理，直接用 Exception、 RuntimeException (连throws也不用）或自己封装一个“BizException”包装错误码和相关信息。

### 4 业务比较精神上头呢？ ###

上面这些还都是在设计时可定义所有异常的情况下遇到的问题。但业务剧烈变化时，不可能初始就预见所有可能问题。强行加Checked Exception对业务系统的接口，是不向前兼容的。

一旦真加了，所有调用方须被逼跟着改：

*  一个系统内部，一个code base（代码库）可能还好处理
 *  对可能跨系统调用（如你写个jar，别人maven依赖），就可能灾难性。如某些组件因种种原因无法升级，就不能使用新代码！

因此，一个好的错误处理体系，最好满足：

*  不会倒逼程序挨个处理无聊异常，允许程序员有选择将关注点放在哪些最关键问题
 *  如团队真要严谨错误处理，可提供一个有力支持，但这支持是团队根据开发的内容来决定使用，而非强制所有语言的使用者都遵循同一套“规则”
 *  允许错误处理渐进性的发展

### 5 Java异常最佳实践 ###

#### 5.1 基建团队 ####

使用Checked Exception，并[定义良好][Link 1]的异常[继承体系][Link 2]，认真处理所有异常。有限度使用RuntimeException

#### 5.2 业务团队 ####

基于RuntimeException定义一个BizException描述各种业务问题，BizExcpetion包含错误码和错误描述信息；同时定义InteralServerError包装各种系统错误，如网络超时。输出http response时，二者输出不同，然后定义不同监控和告警机制

#### 5.3 特定异常 ####

由产研共同商讨设计：

*  哪些可完全不管（如一个不关键数据拿不到），软处理
 *  哪些要前端用户知晓并处理（如登录时用户名或密码错误）
 *  哪些由程序尽量自己处理（如关注的某产品超时，后端要尝试重试几次）

### 6 其他语言处理异常 ###

#### 6.1 go ####

用err（大致等价错误码，但可包含一些数据信息），因此异常可【不捕获而往上抛】的好处就得不到。这可解释为啥很多搞底层开发的不觉go没Exception而难用，因为反正错误都要严谨处理，Exception那点优势不重要。但即便如此，go也不强制调用者必须处理写if err != nil 。

> 但给go加Exception的呼声越来越强烈，应该是 Java 转 Go 的业务开发越来越多。

#### 6.2 js ####

也有Error，但不是很喜欢搞继承。因此javascript一般就只用“Error”，“TypeError”这种简单东西。因为动态语言，开发者可选择自己往Error里塞自己喜欢的东西，并用一些松散的约定解决问题。如：

throw Error("ERR_INVALID_PASSWORD");

简单的用字符串来定义错误。js主要场景在前端，这时出错：

*  要不给用户展示错误信息
 *  要不用错误上报接口报给后端

复杂的异常体系也没用，更谈不上Checked exception。而服务端的NodeJS exception处理就能借鉴很多Java语法。

#### 6.3 kotlin ####

直接砍掉Checked Exception，但保留其他常规异常语法（改成Expression，用起来爽很多）。文档提供两个论据：

*  [Java’s checked exceptions were a mistake][Java_s checked exceptions were a mistake] (Rod Waldhoff)
 *  [The Trouble with Checked Exceptions][] (Anders Hejlsberg)

#### 6.4 swift ####

更有趣，认为\[函数\]的\[异常模式\]有两种：

*  会抛出异常的，于是函数名后边要声明“throws”，但是不需要声明会抛啥异常
 *  肯定不会抛出异常的，所以实现中必须吃掉各种可能发生异常的情况

\[编译器\]会强制确保这个语义的正确。throws这种方式，大概等价于Java中直接throws Exception。

因此从工程角度和语言发展角度来讲，Checked Exception早已经被扔进了垃圾堆。在整个工程项目的错误处理体系里，它的作用已经越来越少。新的语言纷纷抛弃掉这个华而不实的设定。希望广大入场者只要知道Checked Exception是什么就好，实战时还是根据业务场景来设计错误处理。

### 7 结尾 ###

也许还有人觉得Checked Exception是一种可以推进减少程序错误，提高健壮性的好措施。错的是懒惰的，不称职的程序员，而不是Checked Exception。但从我认为，如果一个措施不能有助于解决问题，反而加重问题，那就是无用的。不要把时间和精力浪费在无用的事物。

[Link 1]: https://www.zhihu.com/search?q=%E5%AE%9A%E4%B9%89%E8%89%AF%E5%A5%BD&search_source=Entity&hybrid_search_source=Entity&hybrid_search_extra=%7B%22sourceType%22%3A%22answer%22%2C%22sourceId%22%3A528317237%7D
[Link 2]: https://www.zhihu.com/search?q=%E7%BB%A7%E6%89%BF%E4%BD%93%E7%B3%BB&search_source=Entity&hybrid_search_source=Entity&hybrid_search_extra=%7B%22sourceType%22%3A%22answer%22%2C%22sourceId%22%3A528317237%7D
[Java_s checked exceptions were a mistake]: https://link.zhihu.com/?target=http%3A//radio-weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsWereAMistake.html
[The Trouble with Checked Exceptions]: https://link.zhihu.com/?target=http%3A//www.artima.com/intv/handcuffs.html