大家好，欢迎来到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，私信「神器」即可获得~
免责声明：本站所有文章内容,图片，视频等均是来源于用户投稿和互联网及文摘转载整编而成，不代表本站观点，不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益，请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权，请联系删除，如若转载，请注明出处：https://yundeesoft.com/13154.html
