エラー処理の柔軟性

Question

例外ラッピングを使用することができ、必要に応じて後でキャッチすることができます。 しかし、私が実装したいのは（そしてエレガントに）格納されたprocが呼び出された後にエラーの種類を区別することです。

私はp_errorフィールドに格納されており、procがエラーをダンプします。検証エラー（DBに対する検証を避けることはできません）、または認可エラー（2つの場所、そのうちの1つはDBです）、またはSQLエラーである可能性があります。
要するに、例外をスローする前にエラーの種類を区別するための、きれいで洗練された仕組みが必要です。私が考え

二つのアプローチ：承認のための1、その他のエラーのSQLエラーの1と1：データベースレベルで

1. は3つのエラーフィールドを持っています。これは毛深くなるかもしれない。

2. エラーメッセージが格納され、後でそれを比較できるエラー構造体（enum？）を作成します。もう一度、あまりにも言葉。 db内のエラーメッセージが変わってもメンテナンスが難しい場合はどうすればいいですか？

他のアイデアをお持ちですか？

Answer 1

なぜ人々はこのp_errorナンセンスをやり続けているのかわかりません。少なくともoracle（と私はSQLサーバーでも同様です）では、例外をスローするストアドプロシージャを呼び出した結果は、この愚かなp_errorフィールドよりもはるかに多くの情報を含む発生例外です。

ここでも、私の最近の経験では、Oracleと単純ですが、私は私が想像することはできませんので、この

try { 
    RunMyStoredProcedure(); 
} 
catch(OracleException e) { 
    new OracleExceptionProcessor().HandleException(e); 
} 
//... 
//... 
class OracleExceptionProcessor { 
    static List<int> _validationErrorCodes = new List<int> { 123, 456}; 
    static List<int> _authenticationErrorCodes = new List<int> { 789}; 

    public void HandleException(OracleException ex) { 
    if(_validationErrorCodes.Any(c==ex.ErrorCode)) 
     throw new DatabaseValidationError(ex); 
    if(_authenticationErrorCodes.Any(c==ex.ErrorCode)) 
     throw new DatabaseAuthenticationError(ex); 
    throw new DatabaseSQLError(ex); 
    } 
} 

ような何かを、すべてのストアド・プロシージャ・コール（とにかく標準的な手法）について、その内部のラッパーを記述しますデータベースには多くの検証または認証エラーコードが含まれていますが、これは非常に簡単で簡単です。