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

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


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


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


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


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

一般的情况下：
catch到异常时，把异常System.out.println("什么什么异常发生了")。
这样控制台就有现实，我知道这样只能在开发阶段使用，发布应用使用时就检测不到错误。（web应用，tomcat还是可以报错误，有localhost日志）。

看这篇文章没看出到底具体怎么处理catch到的异常，只是说把日志发到邮箱是个不错的选择。

ps：Exception实现的借口是什么，我忘了，呵呵呵、这东西还得经常看看。

我可能没有写清楚，表达能力比较差。

的确，可以在发生异常的时候使用System.out.println("什么什么异常发生了")来表示发生异常了。这个也符合总的原则： 报告所有异常。 但是相对来说，不一定好的方式： 因为对第一次开发人员来说，看到这条日志是可以清楚的知道出了什么问题，但是发布的时候，首先出现这条消息不一定能引起人们的注意，不一定会发现系统发生异常；另外对于维护人员，看到这条消息来定位错误可能要花费比较长的时间。

很多好的实践更强调系统的维护性：即如何写程序能使将来的维护成本更低。

顺便说一句，最近在看<clean code>，写的很不错。

确实有这两方面的缺点。后面一个缺点可以通过添加这语句（ex.printStacktrace()）来修正。打印出异常抛出时的堆栈信息来解决。

特意看了下异常，这篇文章最佳异常实践（http://blog.csdn.net/pengchua/archive/2008/07/04/2610324.aspx）讲的不错，小小的推荐一下。

==============
有机会看看你推荐的那本书。

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

这要看具体情况， 在我看来， 异常就是一种提示信息， 告诉用户在什么地方出错了

的确，使用unchecked Exception不会产生过多的代码耦合， 但是会带来一个问题， 大家都知道， 对于一个分层的软件结构来说， 每一层所司职责有很大不同， 导致每一层出现异常的表述方式也有很大不同， 如果都一概做成unchecked Exception， 那么就会使得底层的异常直接暴露在用户面前， 而往往这部分异常信息对于用户来说都是不可读的。

所以我认为， 必要的checked Exception也是必须的， 可以严令上一层的开发人员根据自己的模块来将异常转换为用户可理解的异常， 当然， 如果异常可以直接显示给用户， 那么用unchecked Exception还是比较好的。

实际上我一直在思考， 关于异常， 是否我们在滥用， 所以导致这么多纠结的问题呢？

理解这句话。

很高兴听到不同的意见，谢谢各位。

在企业级的应用中，我个人还是认为向spring靠拢，使用unchecked expcetion,毕竟系统中内部调用是相对封闭的，你可以进行控制，而且一次处理就够了，没必要在系统中各层都是异常处理代码，耦合严重。

如果你做个框架或者就是供外部系统调用的，必须让调用者知道发生了什么事情，你无法处理，那么就使用checked expcetion。

另外，spring中如果在事务中抛出了checkedException，spring的事务管理默认是不进行回滚的，必须进行声明，所以如果使用spring还是使用uncheckedException.

做框架的人无法处理的事情，调用者能处理么？如果能，可以举个例子说明么。


这句话看得真累。“必须进行声明”？？