业务逻辑异常和执行异常处理集锦

【业务逻辑异常和执行异常】
对于异常我们只分业务逻辑异常（不符合业务规则的异常）和执行异常（系统自己的异常，比如什么conn出错，某某dll缺少依赖）
业务规则异常自己继承实现一个mylogic异常类就行，无论你是什么dal，你对业务部分异常都抛这个就成
执行异常通常不用管直接写入log4net中，以便维护人员排查错误

 

异常你得分开来看，
一种是可预见异常，简单的例子就是除0啊强转啊导致的，这里异常不但不应该抛出反而应该在逻辑层就被排除掉。
另一种是不可预见的异常，比如数据库连接在执行时突然断了，这类异常完全和逻辑无关，所以放逻辑层处理显然不合适，必须记录日志，可能的话要通知相关人员。

 

☆☆☆☆☆
异常可以分为系统异常和业务异常，业务异常必须被转化为业务执行的结果
DataAccess层不得向上层隐藏任何异常
要明确区分业务执行的结果和系统异常。比如验证用户的合法性，如果对应的用户ID不存在，不应该抛出异常，而是返回（或通过out参数）一个表示验证结果的枚举值，这属于业务执行的结果。但是，如果在从数据库中提取用户信息时，数据库连接突然断开，则应该抛出系统异常

BL层应根据业务的需要捕获某些系统异常，并将其转化为业务执行的结果
UI层除了从调用BL层的API获取的返回值来查看业务的执行结果外，还需要截获所有的系统异常，并将其解释为友好的错误信息呈现给用户
一般使用log4net实现日志记录和自定义异常处理

 

【结论和规范】
只在业务层记录错误，数据层只是抛出

 

参考资料

 

.NET中异常处理的最佳实践（译）

 

 

关于.NET异常处理的思考

 

转载于:https://www.cnblogs.com/xinyf/p/9815872.html