私はトパーズブロックを使用してのAzureへのコールに取り扱う再試行実施しています

Question

の取り扱い過渡障害を使用して非同期操作を再試行してください。カスタム指数バックオフの再試行戦略を実装しました。しかし、私はこの違いを理解するために失敗しています：retrypolicyが満たされているので、最初までマニュアルに従って

var result = await RetryPolicy.ExecuteAsync(() => SomeAsyncOperation()); 

RetryPolicy.ExecuteAsync対

var result = await RetryPolicy.ExecuteAsync(async() => await SomeAsyncOperation()); 

を繰り返し非同期タスクを実行します解決策は、非同期操作の結果を待つので正しいと思われる。しかし、私は両方の方法を試してみて、彼らは同様に動作するようです。 2番目のケースでは、like this oneとthis oneの例も見たことがあります。どちらが正しいか？

Answer 1

これは、コードに冗長な待機時間を導入する非常に一般的な現象です。

例：要するに、私たちはこのような何かを見ています。 で

public Task ExecuteAsync(Func<Task> taskAction) 
{ 
     return taskAction(); 
} 

(1) await ExecuteAsync(() => Task.Delay(5000)); 

    vs : 

(2) await ExecuteAsync(async () => await Task.Delay(5000)); 

（1）あなたが再試行ポリシーに渡されたデリゲートによって作成されたタスクを待っています。 で

（2）あなたはあなたの内側のは、あなたがに待望のタスクの待ちはあなたが待機するために呼び出すときに別のタスクが作成された（1）待つ 、異なるタスク、その時に冗長1を待っていますExecuteAsync。

これは、コードが同じように動作し、ExecuteAsyncによって返されたタスクを待機しているために機能します。 追加のタスクを作成するだけで、途中でもう少し重いことができます（理由はありません）。

RetryPolicy.cs

ExecuteAsync.cs

ここ教訓は、あなたが意図したタスクを待つことです。また

：

そこに守備の冗長化のawaitのうちの充当であるが、非常に重要であり、その冗長のように見えるものも。例えば

：

これは、非同期（exmpale用I/O）操作が完了するまで接続が配置されるべきではない操作 を読み取ります。

await DoSomeReadingAsync(); 

    public async Task DoSomeReadingAsync() 
    { 
     using(var connection = new Connection()) 
     { 
      await SomeReadOperationAsync(connection); 
     } 
    } 

あなたはここでそれを待たずに、内部タスクを返した場合、内部の非同期操作が行われる前に、接続が配置されますので、それは destorusになります。

await DoSomeReadingAsync(); 

    public Task DoSomeReadingAsync() 
    { 
     using(var connection = new Connection()) 
     { 
      return SomeReadOperationAsync(connection); 
     } 
    }