前沿

　　异常设计准则，参考微软msdn，结合自己的理解和过去的开发中对异常错误的处理，总结下软件开发架构，如何更好地设计一套异常错误准则。

介绍准则

execution failure概念

翻译：

架构中处理异常

翻译：

总结准则

　　哪些方法在设计异常时应该被禁止，哪些应该要without hesitation to do，哪些需要考虑，都列在下方的表格中。

　　
　　对第4条做说明：

　　参考的例子代码：

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及其他架构中异常 (Except) 设计准则的详细介绍的内容，更多相关内容请关注PHP中文网（www.php.cn）！