Try/Catch - 奇妙な/複雑なケースで何を捕まえるべきかを私はどのように知っていますか？

Question

私はそうのようなオープンcatchブロックを使用してはならない理由を私は知っている：

int x = 0; 
try 
{ 
    x = GetXFromSomeplaceThatCanFail(); 
} 
catch //Possibly (Exception) or (Exception e) 
{ 
    //Ignore The Failure Because We Don't Care If It Fails 
} 
if (x != 0) //Yes I know I can use finally blocks to do something similar, but this is just an example case 
{ 
    //Do Things With x 
} 

私はこれは悪い習慣であると検出されない障害/微妙なエラーが発生する可能性があり、OutOfMemoryException例外のようなものを「飲み込む」になることを十分に承知していますひどいものです。

だから、私は自分のコードを調べて、このようなものがないことを確認しています。通常は、tryブロックで使用しているもののドキュメンテーションに行き、予期される例外をキャッチするか、特定の操作がインデックスなどの配列にアクセスするときにIndexOutOfRangeExceptionのような特定の例外を生成することを知ります。

しかし、奇妙な状況でどのような例外がスローされるかを確認するためのドキュメントはありません（または見つけるのが難しい）。私自身のプロジェクト（変数名は一般的なものと単純化された変数名）は、文字列フィールドが存在する場合にのみ動的タイプを使用して、かそれ以外の場合は "N/A"を結果として提供できません。繰り返しますが、私はこれは悪いコードであることを知っていることを思い出させる：

string theString = "Some Old Value From Previous Run/etc."; 
try 
{ 
    theString = (placeWhereValuesComeFrom as dynamic).TheString; 
} 
catch 
{ 
    theString = "N/A"; 
} 

をこの文脈では、placeWhereValuesComeFromは（またそれがなければならない）TheStringを提供するdoensn't BaseClassのを継承しています。

TheStringを提供し、BaseClassから継承する中間クラスを作成してから継承することができます。しかし、ダイナミックなソリューションは、設置が非常に速く、うまく機能しました。

theString = placeWhereValuesComeFrom is Subclass ? ((Subclass)placeWhereValuesComeFrom).TheString : "N/A"; 

しかし、私がいないという仮定の下で：よりよい解決策は、私は、中間クラスを追加し、唯一の関連するクラスはそれから継承させる、そのようにようにテストする予定の私の特定のシナリオのために出すされていない限り中間のクラスを使う理由が何であれ、リファクタリングしたいのですが、ここで何をすればいいのですか？キャッチブロックで無視しなければならない可能性のある例外を知るにはどうすればよいですか？例外をスローすることができるだけの "ルックアップ"の方法がない他の同様の状況はどうですか？

Answer 1

ここで扱う例外は、実行時バインドの失敗です。動的オブジェクトがTheStringを実装していないときスローされる例外のタイプはMicrosoft.System.CSharp.RuntimeBinder.RuntimeBinderExceptionです。

だからあなたのコードは、次のようになります。

try 
{ 
    str = myDynamicObject.TheString; 
} 
catch (Microsoft.System.CSharp.RuntimeBinder.RuntimeBinderException) 
{ 
    //Binding failure 
    str = "N/A" 
} 
catch (... //exceptions you know TheString can throw, if any...) 
{ 
    //Handle 
} 
// any other exception you don't know how To handle...don't handle it