0
点赞
收藏
分享

微信扫一扫

Java的checked exception有意义吗?

福福福福福福福福福 09-18 23:15 阅读 2

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

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

初衷很好

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

现实骨感

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

业务系统中,一个典型业务接口,有一个正常处理结果,但可能却有几十个不正常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”包装错误码和相关信息。

业务变化剧烈呢?

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

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

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

因此,一个好的错误处理体系,最好满足:

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

Java异常最佳实践

基建团队

使用Checked Exception,并定义良好的异常继承体系,认真处理所有异常。有限度使用RuntimeException

业务团队

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

特定异常

由产研共同商讨设计:

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

其他语言处理异常

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

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

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

throw Error("ERR_INVALID_PASSWORD");

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

  • 要不给用户展示错误信息

  • 要不用错误上报接口报给后端

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

kotlin直接砍掉Checked Exception,但保留其他常规异常语法(改成Expression,用起来爽很多)。文档提供两个论据:

  • Java's checked exceptions were a mistake (Rod Waldhoff)
  • The Trouble with Checked Exceptions (Anders Hejlsberg)

swift更有趣,认为[函数]的[异常模式]有两种:

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

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

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

结尾

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

举报

相关推荐

0 条评论