GetValue（）メソッドが失敗した場合のエラーの発生

Question

ファイルキャッシュ（サードパーティAPIへのリクエストの結果を表す各ファイル）として機能するWCFサービスを継承しました。現時点でファイルが存在しない場合、コードはデータを作成するための新しい要求を作成し、クライアントコードに対する例外も発生させます。

私は考えているのは、クライアントが再びファイルを要求し、それによって利用可能になるということです（ファイルを生成するのに数秒かかります）。

ここにコードの匂いがあると思います。この部分を書き直す必要があります。現時点では例外が捕捉され、いくつかの方法でバブリングされています。私はファイルが存在するかどうかをソースに設定し、その情報をコールスタックの上に渡す必要があると思います。

1. リターンnullをファイルが存在しない場合：WCFインターフェイスで
   私は現在、2つのオプションがありますが、私はそれを交換するために使用することができると思い、GetValue()方法を持っています。
2. はbool TryGetValue(string key, out string value)方法
を使用し

誰もが任意の設定/推奨を持っていますか？

ありがとうございました

Answer 1

「TryGet」アプローチはもう少し明示されています。 nullを返すアプローチでは、そのような理由でメソッドがnullを返すことを文書化しなければならず、これは開発者がドキュメントを読む必要があります。私たち皆が知っているように、一部の人々は文書を読むことにアレルギーがあります。

"TryGet"アプローチのもう1つの利点は、boolではなくenumを使用して、メソッドが失敗した理由と失敗した方法についてさらに多くの情報を呼び出し側に与えることができることです。

例外の定義のJeffrey Richter's（CLR in C＃）：アクションメンバーがタスクを完了できない場合、メンバーは例外をスローする必要があります。例外とは、アクションメンバーが、その名前で示されているように実行されていたタスクを完了できなかったことを意味します。私の質問は、クライアントでGetValueメソッドを使用できるようにし、データが利用できないときにエラーを発生させるか、それを削除してTryGetValue（）に置き換えるべきかどうかです。

ジェフリーリヒターの定義は、あなたのAPIの設計を決定しているときに役に立ちません。これは、各アクションメンバーのタスクを決定するのに、が含まれているためです。

ご使用のデザインでは、値が使用できないことが予想されます。これは、が値を使用できないという例外的な状況ではないことを意味します。したがって、のTryGet ...パターンを使用します。

しかし、真実を伝えて、私は全く別のアプローチを追求します。誰かがこのアプローチをしようとしたとします

while (!TryGetValue(key, out value)) {} 

か：

SomeType value; 
bool flag = false; 
while (!flag) 
{ 
    try 
    { 
     value = GetValue(key); 
     flag = true; 
    } 
    catch {} 
} 

あなたのWCFサービスは、ヒット曲の多くを取得する予定です。おそらく非同期モデルを調べるほうがよいでしょう。したがって、クライアントにサービスを継続的にポーリングするように依頼するのではなく、結果が準備ができたらコールバックを介してクライアントに通知します。