アプリケーション固有の例外ラッピング「MongoDuplicateKeyExceptionは」必要性のうち

Question

がMongoDuplicateKeyExceptionをラップアプリケーション例外を作成し、例外

public async Task<Response> Method1(parameter ...) 
{ 
    try 
    { 
     //some insert/update operation to DB 
     return <instance of Response>; 
    } 
    catch(MongoduplicateKeyException ex) 
    { 
    var exception = new AppException(ex.Message, ex) 
    { 
     ErrorCode = 22, 
     AppMessage = "some message", 
    }; 

    throw exception; 
    } 
} 

をキャッチして投げる方法で

以下

Public class AppException : Exception 
{ 
    // all constructor implementation 

    public int ErrorCode { get; set; } 
    public string AppMessage { get; set; } 
} 

のように、その例外をスローしているcatch'edありません

上記のMethod1()を呼び出すメソッド

try 
{ 
    //some other operation 
    var response = await Method1(); 
} 
catch(AppException ex) 
{ 
    SomeOtherLoggingMethod(ex, other parameter); 
} 
catch(Exception ex) 
{ 
    SomeMethod(ex, other parameter); 
} 

意外にもをMethod1()から投げても、catch(AppException ex)キャッチブロックがキャッチされることはありません。常に汎用キャッチブロックcatch(Exception ex)をキャッチします。

デバッグ後、catch(Exception ex) catchブロックで例外タイプex.GetType()が実際にWriteConcernExceptionタイプ（MongoduplicateKeyException : WriteConcernException）であることが判明しました。だから、基本的にその特定のcatchブロックは、例外タイプ原因当たっていない

はむしろWriteConcernExceptionしかし

なぜそれがそうであることを確認AppExceptionないではないのですか？私はここに明白な何かを見逃している？提案してください。

Answer 1

デバッグ中に答えが見つかりました。 public async Task<Response> Method1はAppExceptionをスローしないので、ブロックは実行されません。これは、WriteConcernExceptionをスローします。

The API shows WriteConcernExceptionがDuplicateKeyExceptionのスーパークラスであるため、Method1のcatchブロックがヒットせず、例外が呼び出し元の2番目のcatchブロックにバブルします。

したがって、適切な例外をキャッチするようにコードを更新すると、意図した通りに動作するはずです。