使用数据访问层时是否应该将 SqlExceptions 包装在自定义异常中？答案

【问题标题】：Should SqlExceptions be wrapped in a custom exception when working with the data access layer?使用数据访问层时是否应该将 SqlExceptions 包装在自定义异常中？
【发布时间】：2011-06-03 11:30:42
【问题描述】：

如果我是正确的，那么为数据访问对象提供接口背后的想法是，实际存储，无论是数据库、文件还是 XML，对客户端代码都是隐藏的。但是，如果您使用 SqlCommand 和 SqlConnections 并且出现问题并引发 SqlException，则客户端代码会意识到实现以及我们使用 MS Sql 服务器作为数据库的事实。所以我们可以改变客户端代码来捕获 DbException。但随后我们让客户意识到实施。所以这对我来说似乎是一个泄漏的实现。

我认为正确的方法是包装到客户端代码可以响应的自定义 DAL 异常中。

数据库不太可能发生变化。
存储类型（数据库、文件、xml）更不可能改变。

在这种情况下，客户端代码应该只处理 SqlException 本身。客户端代码耦合更紧密，但老实说，我没有看到它发生变化。还是仍然值得包装异常？

【问题讨论】：

您有什么样的处理方式？重试死锁？增加超时？一种解决方案是将任何处理代码放在数据访问层中。

标签： .net data-access-layer

【解决方案1】：

如果您谈论的是持久性无知（并希望保留它），那么正确，您不应该让 SQL 异常冒泡。

您应该创建自己的特定异常类型，并在您的实现中将任何异常与您的自定义异常（PeristenceExcpetion？）包装为InnerException。

话虽如此，如果您知道您没有更改商店类型和数据库，那么就没有理由解耦异常。

【讨论】：

【解决方案2】：

您的应用程序真的是 DBProviderIndependent 吗？您是否总是在内部使用 DbConnection 或 DbCommand 使用 DbProviderFactory 来创建它们？您的项目中没有对 System.Data.SqlClient 的引用？

如果您回答“否”，那么我不会努力翻译异常。 YAGNI

如果我真的需要数据库独立性，我会使用一个特殊的工具来处理异常映射，比如 (Fluent)NHibernate。

【讨论】：