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

Question

我正在为一些关键业务操作编写审计服务。该服务正在使用 IoC 模式实现:

public interface IAuditWriter
{
    void WriteAction(int key, string value);
}

因此，我需要它来引发不特定于实现的异常。

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

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

通常情况下，我讨厌创建一个新的异常类；几乎总有一种合适的类型可以用来传达相同的信息。我过去曾捕获过 System.Data.Linq.DuplicateKeyException ，它看起来是在这里抛出的一个很好的候选者，只不过它来自与 LINQ 相关的命名空间，并且我的界面与我无关使用 LINQ。

我的直接选择似乎是:

• 无论如何都会抛出 System.Data.Linq.DuplicateKeyException 并希望没有人过多地读取命名空间。
• 抛出System.InvalidOperationException并祈祷我永远不需要一个可以因其他原因抛出此异常的实现。
• 抛出我自己的自定义DuplicateKeyException。
• 在界面中创建一个单独的方法来检查键的唯一性，并在写入键和值之前调用该方法。

您对此有何看法？

Answer 1

重新使用另一个命名空间中的异常 有时我会借用基本 .NET 框架中存在的异常，但我认为应该绘制线条。就我个人而言，只是为了重新使用跨越该线的异常而进入 LINQ 命名空间，我不会这样做。

使用 InvalidOperationException 如果看起来不太可能需要专门捕获异常的原因，那么这是一个合理的选择。这里的情况并非如此，所以我也不会这样做。

使用自定义 DuplicateKeyException 这是有道理的。这样的异常很可能是捕获的候选者，因为代码很可能能够对此执行某些操作。异常来自您的命名空间，您可以添加其他相关详细信息以帮助异常处理。

添加“IsUnique”方法 如果在调用“IsUnique”和 WriteAction 方法之间 key 不再唯一(例如由于另一个线程更改了内容)，会发生什么情况？此方法可能很有用，因为如果没有它，代码可能会依赖抛出的异常来检测它(这将是一件坏事)。但是，如果 WriteAction 上的键结果不是唯一的，您仍然需要创建一个异常，甚至不能保证接口(interface)的使用者会首先调用“IsUnique”方法。