江苏龙网

  1. 首页 > 生活 > >

Java设计出checked exception有必要吗

个人觉得这个和Java诞生的背景有关系。

Java语言是一个程序设计工程化的尝试，更少的选择，更标准的编写方式是Java的风格。在这个角度上来说，既然返回值类型是必须声明的，事实上异常也是一种返回值，声明可能返回的异常的类型也很合理。在语言层面上要求程序员对所有返回值（包括异常）进行明确的说明，摒除隐式的rethrow，这个思路是没有问题的。

当然实际运用中我们都知道这是个很失败的语言特性就对了。

■网友
简单来说，Checked Exception是个出发点很好，但是并没有什么卵用的设计。
说出发点很好，是因为我们都知道软件会有各种各样的问题，而严谨的处理这些问题会很好的提高软件的健壮性。Checked Exception的观点是让一个方法指定自己一定会抛什么异常，调用者必须决定一定要处理（catch），或者明确声明继续向上抛（throws）。那么整个程序对异常的处理就非常的明确了，程序员也有章可循，UT，测试也能很明确该处理什么错误。
但是，现实是骨感的。如果说比较接近底层的系统还能相对的设计出比较完备严谨的异常体系的，那么业务系统上这个干是严重吃力不讨好的。在业务系统中，一个典型的业务接口，有一个正常的处理结果，但是可能却有几十个不正常的情况发生。而Checked Exception要求必须每层调用，要不挨个处理，要不挨个声明往上抛。
挨个处理是不现实的，因为大部分情况下，大多数异常都是极端情况，平时很少出现，或者说即使出现了，影响也不大。比如，一个基金的详情，底层可能调用十几个不同的基金信息数据源（基本信息，经理，基金公司，费率，净值，重仓股……）。如果因为意外少个一个两个的，最好的办法是“软处理”。如果是必须使用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可能还好处理。对于可能跨系统的调用（比如你写了一个java lib，别人用maven dependencies依赖），就可能是灾难性的。如果有某些组件因为种种原因无法升级，就不能使用新的代码。
因此，一个好的错误处理体系，最好能满足以下要求：
不会逼着程序挨个处理无聊的异常，允许程序员有选择的把关注点放在哪些最关键的问题上。如果团队真的需要非常严谨的错误处理，可以提供一个有力的支持，但是这个支持是团队根据开发的内容来决定使用，而不是强制所有语言的使用者都必须遵循同一套“规则”。允许错误处理渐进性的发展基于此，我在Team中对Java的异常是这么要求的：


推荐阅读


上一篇：中国的11位手机号码中，都是1开头，那么开头的1有啥意义，为啥不把这位去掉，变成十位

下一篇：为啥直到现在（Firefox50）Firefox浏览器都不支持input type=\＂date\＂