私自身の非LINQコードでDuplicateKeyExceptionを使うべきですか？

Question

私はビジネス上重要な業務の監査サービスを作成しています。サービスは、IoCのパターンを使用して実装されている。このため

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

は、私は、実装に固有ではない例外を発生させることを必要としています。

監査プロセスの情報の一部には、固有のキーが含まれています。監査プロセスの一環として、主要な一意性のチェックを提供するのがサービスの現在の要件です。重複キーはプロセス要件に違反します。

現在、サービスはSQL Serverへの書き込みとして実装されます。ほとんどありませんが、キーが重複している可能性があります。この場合、主キー制約違反に不満を表するSqlExceptionが投げられます。私はむしろこの例外をより一般的な "重複キー"例外で包み込み、捕捉してプロセスが新しい鍵を生成できるようにします。

通常、私は新しい例外クラスを作成することは嫌いです。ほとんどの場合、同じ情報を伝達するのに使用できる適切なタイプがあります。私は過去にSystem.Data.Linq.DuplicateKeyExceptionを捕まえましたが、これはLINQ関連の名前空間に由来することを除いて、ここに投げられる良い候補のように見え、私のインターフェイスはLINQとは何の関係もありません。

私の当面のオプションがあるように見える：

• 投げSystem.Data.Linq.DuplicateKeyExceptionとにかく誰もがあまりにも多くの名前空間に読まない願っています。
• System.InvalidOperationExceptionを投げて、私の指を渡してください。他の理由でこの例外を投げることができる実装は決して必要ありません。
• 私自身のカスタムDuplicateKeyExceptionを投げてください。
• インターフェイスに別のメソッドを作成してキーの一意性をチェックし、キーと値を書き込む前にこれを呼び出します。

これについてのご意見はありますか？

Answer 1

の時間に別の名前空間 から例外を再使用して、私はベースの.NETフレームワークには存在しますが、私は引かれた線があるはずだと思うの例外を借ります。個人的には、例外を再利用するためにLINQ名前空間に手を差し伸べると、私はそれをやりません。それは、具体的例外の理由をキャッチ必要であろうことを非常に低いと思われる場合に使用する合理的な一つです

使用InvalidOperationExceptionが 。これはここには当てはまらないので、私はそれもしません。

カスタムDuplicateKeyExceptionを使用する これは意味があります。そのような例外は、可能性のあるコードがそれについて何かできることがあるので、キャッチする可能性が高い候補です。例外はネームスペースに由来し、例外処理を補助するために他の関連する詳細を追加できます。

「IsUnique」とごWriteActionメソッドの呼び出しの間でキーがユニークでなくなるとどうなりますか、物事を変え、別のスレッドによると言う？「IsUnique」方法 を追加しますか。このメソッドを使用しないと、コードを検出するためにスローされた例外にコードが依存する可能性があるため、このメソッドは便利です（悪いことです）。ただし、WriteActionでキーが一意でないことが判明した場合でも例外を作成する必要があります。インターフェイスのコンシューマが最初に「IsUnique」メソッドを呼び出すという保証はありません。