异常设计准则，参考微软msdn，结合自己的理解和过去的开发中对异常错误的处理，总结下软件开发架构，如何更好地设计一套异常错误准则。
The meaning of execution failure: execution failure occurs whenever a member cannot do what it was designed to do (what the member name implies). For example, if the OpenFile method cannot return an opened file handle to the caller, it would be considered an execution failure.
翻译：
操作失败的意思：无论什么时候一个成员模块不能完成它预期的任务时，就称为发生了一次操作失败。例如OpenFile方法不能给caller返回一个打开文件的句柄，这就是一次操作失败。
In the Framework, exceptions are used for all error conditions, including execution errors.
翻译：
在框架中，异常被用来处理所有的错误条件，包括执行错误。
哪些方法在设计异常时应该被禁止，哪些应该要without hesitation to do，哪些需要考虑，都列在下方的表格中。
| 编号 | 方法 | 做法 |
|---|---|---|
| 1 | 返回错误代码 | 禁止 |
| 2 | 执行错误，要抛出异常；如OpenFile()未返回文件句柄 | 建议 |
| 3 | 假如代码再继续执行就变得不安全时，考虑是调用System.Environment.FailFast终止进程还是抛异常。 | 考虑 |
| 4 | 如果有可能的话，在正常的控制流处，抛异常，见下面的分析 | 禁止 |
| 5 | 抛异常对性能的影响。 | 考虑 |
| 6 | 协定中纳入异常处理部分 | 建议 |
| 7 | 将异常作为返回值返回 | 禁止 |
| 8 | 使用异常生成器方法，为避免代码膨胀, 用helper方法创建异常和属性. | 考虑 |
| 9 | 异常筛选器中抛出异常. | 禁止 |
| 10 | 从finally 块中显示地抛出异常 | 禁止 |
对第4条做说明：
In daily coding, consider the Tester-Doer pattern for members that may throw exceptions in common scenarios to avoid performance problems related to exceptions. The Tester-Doer pattern pides a call that might throw exceptions into two parts: a Tester and a Doer. The Tester performs a test for the state that can cause the Doer to throw an exception. The test is inserted just before the code that throws the exception, thereby guarding against the exception. 来自http://blog.csdn.net/troubleshooter/article/details/18401491
参考的例子代码：
Tester和Doer各司其职，完美的减少了异常抛出，提升性能。
Doer：上面的状态监测是好的，才能DoProcess()处理；如果是false，并且如果DoProcess()中包括DoCheck()逻辑，则会抛出异常，但是这样分隔开后，DoProcess()将不会抛出异常！
if(DoCheck()==true)//这是Tester:状态监测
DoProcess();软件开发常见异常及处理方式（自己总结）
1 UI层暴露出的操作接口，建议包裹try{}catch{}块，catch中将抛出的异常写入到磁盘中。
2 UI层中用到计时器时，计数器的回调函数出现异常后，要stop掉计时器，防止错误日志一直写进文件中。
3 底层建议不包裹try{}catch{}块，建议用throw直接抛出异常，因为UI层上包裹了try{}和catch{}块，所以没必要写在这些层。
4 throw会直接中断以后操作，跳转到所属堆栈外层包裹try{}和catch{}，即UI层，利用这个性质，一般建议函数不要返回错误码。
5 处理批量导入的数据时，局部出现异常。Excel导入人员，设备，计划，物料，工艺等，如果某一行数据违规了，这时候不建议抛出异常，因为一旦抛出异常，意味着后面行的数据导入不进来，并且已经导入进去的成为脏数据。
一般有两种做法：某行出现违规数据，记录到日志文件中，日后根据这个文件查到那条数据未导入，然后单独处理这一条即可；在导入前，直接检查所有行的数据是否合法，检查无误后，再一一导入，否则直接弹出提示，任何数据都写不到数据库中。一般建议后者做法。这种做法称为：Tester-Doer异常模式，也是微软建议的做法。
6 处理看板展示数据，局部出现异常。这个处理模式跟5是有区别的，一般此时出现异常，往往采取5的前者做法：展示出正确的数据，违规的数据写入到日志中，留待查看；但是也有可能，如果展示的界面，主要的数据不存在，则直接抛出异常，写入日志，通过日志解决。因此要根据数据的异常严重程度去处理。
7 根据开发文档、日志，分析，尽量做到能够找到某个功能未实现的原因。首先要保留好开发文档，查看用户现在的要求是不是和开发文档中的一致。如果一致，此时日志的作用就显示出来了，例如，汇总一周内所有工序的完工饼状图，如果一条工序数据都没有，那么饼状图可能就没有，在开发过程中，如果检查了是不是存在工序，如果没有找到一条工序，可能会抛出异常，然后写入日志地话，原因就会找到。因此这类问题，也要写入日志，尽管它不是错误，但可以归为异常。
8 函数返回一个对象，其方法和属性被后续逻辑引用。这是不可避免的！并且大部分功能的实现都依赖于此。返回的这个对象因为要被后续引用，所以建议做null比较，如果为null，是传递给UI层，弹出消息提示，还是直接抛出异常，UI层处理后写入日志，视情况而定。
以上是.NET框架-异常设计原则详解的详细内容。更多信息请关注PHP中文网其他相关文章！
