数据访问层中的异常处理策略答案

【问题标题】：Exception handling strategy in Data Access Layer数据访问层中的异常处理策略
【发布时间】：2012-11-21 10:07:10
【问题描述】：

我正在构建一个数据访问层，它将用于两种类型的应用程序。

不关心错误细节的应用程序。如果发生异常，那么很可能只是被记录下来，而用户可能没有意识到这一点。

示例：简单的条码盘点应用。用户输入条形码，如果数据库连接可用，则系统提供一些额外信息，如果没有，则仅在本地记录条形码。在这种情况下，我不想要详细的异常处理。
我非常关心异常细节的应用程序。

在构建我的 DAL 以适应这两个类别时，我必须遵循什么策略？

现在我正在从第一类构建一个应用程序，我在 DAL 方法中所做的只是让异常冒泡到表示层，在那里我有几个 try..catch 块以简化处理日志记录，让用户不知道他的错误。

【问题讨论】：

您的 DAL 不应该关心它是如何被使用的。让它抛出有意义的异常，让你的消费层/应用程序处理它们认为合适的方式。听起来你使用的策略已经考虑到了这一点，所以我认为你不需要改变任何东西。
避免使用异常来控制程序流程。使用它们来指示未预料到的异常情况。这意味着您的 DAL 将决定何时在连接可用时保留数据。
@EliGassert：这意味着演示中的多个 try catch 块或制作某种自定义异常处理类... MushinNoShin：在某些情况下数据将永远不可用（例如，如果 3G 网络出现故障和平板电脑无法连接）

标签： c# .net exception-handling data-access-layer

【解决方案1】：

错误处理是从需要知道的人知道的代码部分获取信息。 DAL 知道如何打印 SqlException、SqlCommand 和 SqlParameters 集合的踪迹。但是 UI 知道导致异常的整个调用堆栈。用户可能不知道如何处理这些信息，因此您应该登录到单独的渠道，例如向开发人员发送电子邮件或登录数据库。

如果您正在编写错误记录器，我还建议您使用一个真实的应用程序（或几个真实的应用程序）作为您的库的测试。例如，您可以将错误记录器连接到 codeplex 上的各种应用程序，看看解决错误时的痛点，或者尝试 dogfooding 并使用错误记录器记录错误是您自己的库。

【讨论】：

所以你是说不要试图捕获所有东西（通过在每个方法中放置 try catch）并且还要尝试在最高级别捕获异常，因为我有整个堆栈跟踪来查看所有底层水平。正确的？所以在我的情况下，因为我有一个 dal 和一个表示层，我将不得不像现在一样在演示文稿上做它......
是的，错误记录通常最好在堆栈顶部完成。但是，在引发错误后，您仍然可能会捕获并重新引发新错误或执行特定于库的日志记录。在 C# 中注意 throw 的不同； vs 扔新的 XXX；后者将 trucate 调用堆栈，前者不会。
我使用Elmah记录所有抛出的异常，我推荐它，它真的很好用，不需要在每个方法中都放try/catch。