<高效程序员的45个习惯>精简版读后感 -- 报告所有的异常

不报告所有异常有什么坏处

例如：你在一个方法里捕获了一个异常，但是在catch里没有做任何事情，也没有向外扩散这个异常。那么，当日后程序在生产环境中运行时发生错误，抛出这个异常时，方法返回了，运行结果错误，最终用户看不到任何错误提示。bug修复人员也无法很快定位错误，因为错误的表现形式是多样的，唯一能做的就是一步步调试找到错误的位置。如果碰巧这个bug的环境很难重现的话，对开发人员来说是一场灾难。

为什么要报告所有异常

1大部分异常都是程序出现错误，很难恢复。出现的错误后应该第一时间展示出来，否则，这个问题在以后也会通过其它形式展示，这样排错的代价更高。

2在程序运行发生问题时，开发人员，测试人员，最终用户等能清楚的明白:程序出问题了，在哪里出了问题，出了什么问题。

3注意这里说的“报告”并不一定就是非要把异常传播到最高层打印到控制台上，有时候可能只是记一条错误日志，或是发送一条消息，电子邮件。

为什么实践中大家(至少我是这样)常常没有遵守这一点

1低级别选手对异常本身就含糊不清；

2java的异常架构(受检和非受检)本身就有相当的争议，个人认为主要原因在于这种架构容易让人误用，包括JDK的开发者；

注：RobertMartin也认为受检的异常并不好，主要原因是在异常向上传播时，会让每一个方法都受影响(每个方法的定义里都必须抛出异常)，结果就是代码耦合性强。条件允许的情况下，尽可能使用非受检异常。

3从一些书中可以找到一些好的实践，但是系统性的，权威性的说明好像还没有看到。

实践做法

1普通的应用程序(如桌面应用)直接把异常往外层扩展。

2如果自己做框架，尽量把异常包装成uncheckedexception，类似spring的做法，这样就不用写扩展代码而把异常扩展到最高层。

3在无法扩展异常到外层时(例如web应用)，捕获异常后，通过各种方式，例如日志，邮件来报告异常。

注：实践中，发邮件可能是个比较好的方案，例如：可以对一段时间内发生的错误汇总起来，一起发给系统管理人员。如果只记日志效果不一定好，一是错误可能淹没在日志里，二是系统管理人员事情太多，不一定有这个精力去持续关注日志。

注：上面若干想法来自于<高效程序员的45个习惯>精简版，effectivejava等书。如有雷同，不是巧合。另外，最近在看RobertMartin的<CleanCode>，看完后可能会有不同的观点，到时再更新。