该层和WebUILayer的配置除AlertType为WinUI方式外，基本一致。

　　以上配置为开发调试方式时，若是在发布到测试或正式环境，只需要把WinUILayer和WebUILayer中的ReturnMode属性更改为ErrorString方式，即可让用户看到的是友好的错误信息。

　　补充：WinUI项目的异常日志记录器可以再增添一个本地异常Log文件方式，当发生异常时，可以根据用户提供的Log文件进行分析。

　　项目中调用

　　在写好配置文件之后，项目中引用ExManagement包。调用方法如下，项目中任何地方调用处理方式完全一致

// 返回值根据用户配置而不同，可以为ErrorId， ErrorString以及ExceptionString

string strMessage;

try

{

;

}

catch(Exception ex)

{

// 参数ex， 异常对象

// 参数"BLL001"， ErrorId， 即错误编号

// 参数"BusinessLogicLayer"， ExHandlerName， 即异常处理器名称， 建议于层名称对应

// 参数UserId， 即当前用户Id

ProcessExeception(ex， "BLL0001"， "BusinessLogicLayer"， UserId);

}

　　四、效果评价

　　可配置性。通过该异常处理框架可以方便的对异常处理进行需要的配置。可配置的内容：

　　可以配置多个异常日志记录以不同的方式记录在不同的位置;

　　异常处理方式可以有多种：抛出包装后异常对象、 返回详细的异常信息(调试用)、返回错误提示信息(发布后给用户看)以及错误编号;

　　灵活性。建立在可配置性的基础上，可以组合出多种异常处理方案，以满足不同项目的特殊需要。

　　开放的可扩展性。用户可以自行实现框架提供的接口，自行扩展异常处理以及异常日志记录的类，以插件形式供框架调用，以实现大可能的灵活性。

　　性能。因为使用了不少反射技术，在性能上有一定损耗，但使用了单例模式来弥补，只在项目第一出现异常的时候反射加载对象，以后再次调用时则直接使用该对象，对效率基本没有任何损耗了。

　　而多数情况下，以框架提供的默认解决方案已经能够满足普通项目的需要，提供一个功能比较完整的，健壮的异常处理机制：

　　1) 方便和简化了开发人员及时定位和发现异常原因;

　　2) 对系统运行状况提供了强有力的数据支持，并使错误信息统一的方式管理，可以改善用户体验;

　　3) 当项目在用户使用中发现运行错误时，可以记下系统反馈的异常记录编号后于项目开发人员联系，而开发人员可以根据记录编号得到异常发生的详细信息进行分析。有助于缩短项目异常反馈时间。

　　五、推广建议

　　该异常处理框架基本适合所有.Net项目，因为可以灵活的配置以适应不同项目的具体需要。

　　在一个项目推广中，只需要有一个人比较深入的了解该异常处理框架的原理以及如何进行配置和自定义扩展开发，掌握时间大概只需要半天到时间。而项目中其他人员无须知道该框架的运行机制，他们只需要在每个捕捉异常的地方用同样的、的方法调用框架即可。

　　因为该框架对于项目而言是高度聚合，低耦合的，对于项目而言不需要知道异常究竟会被如何处理，减少对项目的依赖。因此对于现有异常处理系统存在不足以及新项目是应该大力推荐使用该框架进行异常处理的，并且对现有项目的改造工作不大;当然也可以选择对项目已有部分不改动，新开发部分进行使用该框架进行异常处理也是完全可以的。

　　异常处理框架本身没有做任何自身的异常情况处理，所以在采用框架的时候需要先按照预想的配置在模拟环境中进行调试，确认能够正常运行之后再加入到正式项目中去，避免在正式环境中出现框架本身异常无法判断的情况。

　　当然因为异常处理的可能方案比较多，该框架的第一个版本可能会有遗漏的可能，但因为框架本身的良好扩展性，多数的特殊情况应该可以用户自行扩展解决。若有无法解决的可以和我联系，对框架本身代码做调整，以求完善该框架。

　　另外，该异常处理框架若与近讨论比较热门的AOP(Aspect Oriented Programming面向方面编程)思想结合可以大程度使系统的业务代码和系统异常处理代码完全分离，并提供更为准确的异常信息。因AOP技术目前在发展阶段，并需要完全的纯OOP项目中实施，暂不对此展开讨论。