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

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

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

因此,我需要它提出一些不特定于实现的异常。

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

SqlException 将抛出,抱怨主键约束冲突。我宁愿将此异常包装在一个更通用的“复制密钥”异常中,该异常可以被捕获,然后允许流程生成一个新密钥。

通常,我讨厌创建一个新的异常类;几乎总是有合适的类型可以用来传达相同的信息。我赶上了火车 System.Data.Linq.DuplicateKeyException 在过去,这看起来像是一个很好的候选,除了它来自一个与LINQ相关的名称空间,我的接口与LINQ无关。

我眼前的选择似乎是:

• 投 System.Data.Linq.DuplicateKeyException 无论如何,希望没有人对名称空间读得太多。
• 投 System.InvalidOperationException 我祈祷我永远不需要一个实现,它可以因为其他原因抛出这个异常。
• DuplicateKeyException .
• 在接口中创建一个单独的方法来检查键的唯一性,并在写入键和值之前调用它。

你对此有何看法?