精简版读后感 -- 报告所有的异常

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


[size=large][color=blue]为什么要报告所有异常[/color][/size]
[size=medium] 1 大部分异常都是程序出现错误，很难恢复。出现的错误后应该第一时间展示出来，否则，这个问题在以后也会通过其它形式展示，这样排错的代价更高。
2 在程序运行发生问题时，开发人员，测试人员，最终用户等能清楚的明白: 程序出问题了，在哪里出了问题，出了什么问题。
3 注意这里说的“报告”并不一定就是非要把异常传播到最高层打印到控制台上，有时候可能只是记一条错误日志，或是发送一条消息，电子邮件。[/size]


[size=large][color=blue]为什么实践中大家(至少我是这样)常常没有遵守这一点[/color][/size]
[size=medium] 1 低级别选手对异常本身就含糊不清；
2 java的异常架构(受检和非受检)本身就有相当的争议，个人认为主要原因在于这种架构容易让人误用，包括JDK的开发者；
[color=red]注： Robert Martin也认为受检的异常并不好，主要原因是在异常向上传播时，会让每一个方法都受影响(每个方法的定义里都必须抛出异常)，结果就是代码耦合性强。条件允许的情况下，尽可能使用非受检异常。[/color]
3 从一些书中可以找到一些好的实践，但是系统性的，权威性的说明好像还没有看到。[/size]


[size=large][color=blue]实践做法[/color][/size]
[size=medium]1 普通的应用程序(如桌面应用)直接把异常往外层扩展。
2 如果自己做框架，尽量把异常包装成unchecked exception，类似spring的做法，这样就不用写扩展代码而把异常扩展到最高层。
3 在无法扩展异常到外层时(例如web应用)，捕获异常后，通过各种方式，例如日志，邮件来报告异常。
注： 实践中，发邮件可能是个比较好的方案，例如： 可以对一段时间内发生的错误汇总起来，一起发给系统管理人员。如果只记日志效果不一定好，一是错误可能淹没在日志里，二是系统管理人员事情太多，不一定有这个精力去持续关注日志。[/size]


[color=red]注：上面若干想法来自于<高效程序员的45个习惯>精简版， effective java等书。如有雷同，不是巧合。另外，最近在看Robert Martin的<Clean Code>，看完后可能会有不同的观点，到时再更新。[/color]