我应该在自己的非LINQ代码中使用DuplicateKeyException吗？

Question

我正在为一些业务关键型操作编写审计服务。该服务正在使用IoC模式实施：因此，我需要它提出不特定于实现的异常。

审核过程中的部分信息包括一个旨在唯一的密钥。作为该服务的当前要求，其作为其审核过程的一部分提供对关键唯一性的检查。重复密钥违反了流程要求。

目前，该服务将作为写入SQL-Server的方式来实现。尽管不太可能，但可能该密钥可能是重复的，在这种情况下，会抛出SqlException抱怨主键约束违规。我宁愿将这个异常封装在一个更通用的“重复键”异常中，这个异常可以被捕获，然后允许进程生成一个新的键。

通常，我讨厌创建一个新的异常类;几乎总是有一个合适的类型可用于传达相同的信息。过去我已经抓到了System.Data.Linq.DuplicateKeyException，除了它来自LINQ相关的命名空间外，看起来像是一个很好的候选者，而且我的界面与LINQ没有任何关系。

我急迫的选择似乎是：

• 投掷System.Data.Linq.DuplicateKeyException无论如何，希望没人看到的命名空间太多了。
• 丢弃System.InvalidOperationException并穿过我的手指我从来不需要一个可能因其他原因而抛出此异常的实现。
• 扔我自己的自定义DuplicateKeyException。
• 在接口中创建一个单独的方法来检查密钥唯一性，并在写入密钥和值之前调用它。

你对此有什么看法？

Answer 1

重新使用来自另一个命名空间异常 有时我会借存在于基本NET框架异常，但我觉得应该有行绘制。亲自进入LINQ名称空间只是为了重新使用异常而跨越那条线，我不会这样做。

使用InvalidOperationException 这是一个合理的使用，如果似乎不太可能需要专门捕获异常的原因。这不是这种情况，所以我也不会那样做。

使用自定义DuplicateKeyException 这是有道理的。这样的例外可能是捕捉的候选对象，因为它很可能代码可能能够做些什么。异常来自你的名字空间，你可以添加其他相关的细节来帮助异常处理。

由于另一个线程改变事物添加“isUnique设置”方法 发生什么情况，如果在调用“isUnique设置”和你的WriteAction方法的关键停止是唯一的之间，说什么？这种方法可能是有用的，因为没有它，代码可能依靠抛出异常来检测它（这将是一件坏事）。然而，如果在WriteAction上关键的结果不是唯一的，你仍然需要创建一个异常，但不能保证接口的使用者甚至会首先调用“IsUnique”方法。