C# asp.net中的异常处理

只是尝试一下企业库4.0中的异常处理块。我的应用程序是一个asp.net应用程序，它有DAL、BLL和UI

当发生异常时，我想记录相关场景/上下文，包括DAL（sp、参数、异常）、BLL（用户、角色等）和UI（会话内容）。现在我想我需要用字典创建一个自定义异常。当DAL中发生异常时，我会在异常冒泡时在每一层用相关数据填充字典。最后，我将其记录在App_Error

web上的示例建议将其记录在DAL上，然后发布。在BLL、UI层，我们如何处理这样一个传播的异常？这是否意味着，它与保存上下文相同，但每个层本身都会记录相关数据。然后在日志中，我们需要关联每一层的日志语句来创建上下文

---

请建议…

在我实施的所有解决方案中，常识通常要求您只报告DAL的错误

通过事务性地执行任何db更改，您将确保执行回滚，并用您自己的异常包装实际异常，该异常表示发生了内部异常，因此未进行任何更改

在BLL中，异常被捕获，然后作为调用应用程序的自定义“BusinessProcessException”被进一步抛出。可以选择使用BLL，因为它位于自己的“盒子”中，可以说有时有自己的日志记录机制来记录与业务流程相关的异常

无论是否在BLL层记录了异常，您仍然需要通知UI层（客户端应用程序）发生了异常，并通过返回完整的异常树记录了异常

UI层中的客户机应用程序代码可能有自己的日志，但BLL不会使用该日志

事件周期是这样的

应用程序调用bll方法 bll方法调用dal方法 dal方法调用数据库上的存储过程 存储过程错误引发（例如）sql异常 dal抛出新的dal异常，sqlexception作为内部异常 bll处理dal异常并记录dal失败 如果调用的bll方法中有一些事务元素，bll将回滚其他调用。 bll抛出新的bll框架异常内部是dal异常 应用程序处理bll异常，并决定如何从完整异常树继续用户体验

几乎所有.net都是这样工作的

注意事项：

如果某个业务对象的更新调用失败，则该业务对象可能有多个子对象，这些子对象作为该调用的一部分进行更新。 这些子对象可以从不同服务器上的多个dal端点组装而成，并且每个dal端点可能必须更新多个数据库中的多个记录

因此，对于bll逻辑有一个事务，对于每个dal调用内部工作有一个事务，然后在每个存储的proc调用中可能有一个事务

net在后台所做的是以这样一种方式对这些事务进行堆栈：如果bll级别的事务失败并调用回滚，则它应该回滚所有子事务，但是在事务跨越系统和网络的现实世界中，这可能是不可能的

因此，您必须假设您所采取的操作可能会失败，并且如果继承权的任何部分失败，并且进行调用的代码对此负责，那么您所采取的操作可能会回滚

这最终意味着您需要对发生的事情进行全面的审计跟踪。 作为一个bll开发人员，我会记录我的框架所做的一切，sql也有事务日志，因此许多dal实现在这方面都得到了简化

应用程序只有（对于asp.net）服务器日志或自定义选项

---

我唯一建议的是，每个层都记录自己的活动，并且日志是分开的（例如，与ui相关的错误实际上不属于bll日志）

您不能只使用内部异常，并让它指示层的移动吗？+1这里有一个很好的建议，虽然我传统上不为DAL设置单独的日志，因为它通常只是由BLL驱动。是的，我同意我倾向于依赖sql自己的事务日志。。。但是，如果您不使用sql后端，并且需要对所执行的操作进行审计跟踪，那么bll日志不会始终为您提供清晰的图像（取决于设计和规模）。。。所以我喜欢涵盖所有的基础。当一个问题发生时，你会感激所有你能得到的关于它的数据！！！！