36 告所有的异常

1. 问题是什么/h2>

从事任何编程工作，都需要考虑在正常情况下，软件要做什么过更应该想一想，当出现问题——也就是事情没有按计划进行时，会发生什么/em>

夫子曰：敏捷调试的基础是什么言之，我们在分离出问题之后，下一步时干什么/p>

收集问题发生时的信息，问题发生时，被调用接口反馈的异常信息，就是一个很好的信息收集途径。这也要求我们在设计接口时，一定要定义恰当的异常返回值。

2. 恶魔的主意

不要让程序的调用者看到那些奇怪的异常。处理它们是你的责任。把你调用的一切都包起来，然后发送自己定义的异常——或者干脆自己解决掉。

夫子曰：这真是”恶魔“出的主意，有异常时，欺上瞒下，不让接口的调用者了解发生的情况，出现情况后，怎么去处理呢/p>

3. 天使的主意

处理或是向上传播所有的异常

心里感受

当出现问题时，心里知道能够得到抛出的异常。而且没有空的异常处理办法

4. 有没有天使不在的时候/h2>

• 决定有谁来负责处理异常，是设计工作的一部分
• 不是所有的问题都应该抛出异常
• 告的异常应该在代码的上下文中有实际意义
• 如果代码运行时，会记录日志。若捕捉或抛出异常时，要记录日志信息
• 检查异常处理起来很麻烦。没人愿意调用抛出31种不同异常的方法，这是设计上的问题，要解决掉。
• 要传播不能处理的异常

5. 总结

夫子曰：被调用者发生异常后，要告诉用户发生了什么！

被调用者执行出现异常后，若可以处理，恢复到正常，则自己处理；若不能处理，则保存现场信息，向用户，也就是调用者反馈异常信息。但也不能传递过多异常，如书种所述，调用一个可以反馈30多个异常的接口，岂不是梦魇/p>