何时抛出异常异常

我们写程序时经常遇到错误处理的情况，尤其是面向用户的应用程序（区别于面向开发人员的组件，类库）。笔者经常在写ASP.NET应用程序的时候，经常在返回错误代码和抛出异常之间徘徊，犹豫。即舍不得抛出错误代码这种方式的简洁，方便，又唯恐不使用抛出异常从而违反了.NET的设计准则。比方说，我们要写一个删除用户的方法，那么这个方法是要定义为void类型通过异常来处理删除失败的情况呢，还是定义为Boolean返回值来通过true或 false来返回删除的结果呢，笔者不得而知。为此，笔者捶胸顿足，不得安寝。于是笔者参考了两本猛书《.NET 框架程序设计》和《代码大全》，通过引用这两本书上的一些话来小作分析（书中的原文都用黑体标出）。

首先，我们讨论异常，还是要先知道异常是个什么东东。《.NET 框架程序设计》是这么定义的：“异常是对程序接口隐含假设的一种违反”。

这里面还有两个名词需要解释：”程序接口“和"隐含假设"。程序接口就是类型定义中的字段，属性，方法，事件等，这些成员的定义就是类型的程序接口。我们定义的接口通常会有一些隐含的假设，比方说删除用户的方法应当假设用户是存在的（对参数的假设），数据库连接是可用的（对执行环境的假设）等等。当这些程序接口中出现的假设呗违反时，异常就出现了。也就是说出现这两种情况时，我们应该抛出异常来反应这种违反程序接口假设的方法。

“因此，在设计一个类型是，我们应该首先假设类型最常见的试用方式，然后设计接口能使之能够很好的处理这种情况。最后再考虑接口带来的隐含假设，并且当任何这些假设被违反时便抛出异常。” 因此，异常不必然是错误，也不是什么无法预料的特殊情况，而是对程序接口隐含假设的一种违反。

下面给出一些《代码大全》中关于使用异常的忠告：

1. 只有在真正例外的情况写才抛出异常。换句话说，就是仅在其他编码实践方法无法解决的情况下才使用异常。异常的应用情形跟断言相似，都是来处理那些不仅罕见甚至永远不该发生的情况。

2. 不能用异常来推卸责任。如果某种的错误情况可以在局部处理，那就应该在局部处理掉它。不要把可以在局部处理掉的错误当成一个未被捕获的异常抛出去。

3. 创建一个集中的异常报告机制。有种方法可以确保异常处理的一致性，即创建一个集中的异常报告机制。这个集中的报告机制能够为一些与异常有关的信息提供一个集中的存储，如所发生的异常种类，每个异常该被如何处理及如何格式化异常消息等。

最后，奉上《代码大全》中的一句话，从应用程序的角度来解析错误处理，我看完有点顿悟的感觉。

应对应用程序运行时发生的严重错误的最佳做法，又是就是释放所有已获得的资源并终止程序执行，而让用户去重新输入数据再次运行程序（Stroustrup 1997）。

其实异常只是一种机制，不能因为编程语言中有这种机制而去使用异常，还有好多错误处理机制：在局部处理错误，使用错误代码来传递错误，在日志文件中记录调试信息，关闭系统等，这些方式应该灵活的应用，也许是单独地，也许可以交叉的使用，最终应该以两个标准来确定错误处理方式：用户的体验和设计的鲁棒性。