阿里面试官：Error和Exception-实践篇

大家好，欢迎来到IT知识分享网。

周末愉快呀！今天的Emma仍然是勤奋更新的小天使～

上一期推文里，我跟大家聊了很多概念性的东西。（错过的亲，请去补课哦，速度速度！）

俗话说的好：

「 不能实践的理论都是耍流氓 」

那今天Emma就来跟大家谈点实践中的选择，我会结合一些代码用例进行分析。

先看第一个吧，下面的代码反映了异常处理中哪些不当之处?

这段代码虽然很短，但是已经违反了异常处理的两个基本原则：

再来看看第二段代码：

这段代码作为一段实验代码，它是没有任何问题的，但是在产品代码中，通常都不允许这样处理。你先思考一下这是为什么呢? 我们先来看看printStackTrace()的文档，开头就是“Prints this throwable and its backtrace to the standard error stream”。

问题就在这里，在稍微复杂一点的生产系统中，标准出错(STERR)不是个合适的输出选项，因为你很难判断出到底输出到哪里去了。尤其是对于分布式系统，如果发生异常，但是无法找到堆栈轨迹(stacktrace)，这纯属是为诊断设置障碍。所以，最好使用产品日志，详细地输出到日志系统里。

我们接下来看下面的代码段，体会一下Throw early, catch late原则。

如果fleName是null，那么程序就会抛出NullPointerException，但是由于没有第一时间暴露出问题，堆栈信息可能非常令人费解，往往需要相对复杂的定位。

这个NPE只是作为例子，实际产品代码中，可能是各种情况，比如获取配置失败之类的。在发现问题的时候，第一时间抛出，能够更加清晰地反映问题。

我们可以修改一下，让问题“throw early”，对应的异常信息就非常直观了。

至于“catch late”，其实是我们经常苦恼的问题，捕获异常后，需要怎么处理呢？

最差的处理方式，就是我前面提到的“生吞异常”，本质上其实是掩盖问题。如果实在不知道如何处理，可以选择保留原有异常的cause信息，直接再抛出或者构建新的异常抛出去。在更高层面，因为有了清晰的(业务)逻辑，往往会更清楚合适的处理方式是什么。

有的时候，我们会根据需要自定义异常，这个时候除了保证提供足够的信息，还有两点需要考虑:

业界有一种争论(甚至可以算是某种程度的共识)，Java语言的Checked Exception也许是个设计错误。

反对者列举了几点:

我们从性能角度来审视一下Java的异常处理机制，这里有两个可能会相对昂贵的地方:

问题是，实际上可能吗？小范围或许可能，但是在大规模项目中，这么做可能不是个理智的选择。如果需要堆栈，但又没有收集这些信息，在复杂情况下，尤其是类似微服务这种分布式系统，这会大大增加诊断的难度。

当我们的服务出现反应变慢、吞吐量下降的时候，检查发生最频繁的Exception也是一种思路。关于诊断后台变慢的问题，我会在后面的Java性能基础模块中系统探讨。

今天，我从一个常见的异常处理概念问题，简单总结了Java异常处理的机制。并结合代码，分析了一些普遍认可的最佳实践，以及业界最新的一些异常使用共识。最后，我分析了异常性能开销，希望对你有所帮助。

Emma的福利环节

今天给大伙儿送上的是“刷题神器”哟~

LintCode VIP 7天免费使用

2000道算法真题随意刷，国内外大厂ladder针对性训练，自我提升法宝、求职备战利器！

领取方式：

关注Emma，私信「神器」即可获得~