例外処理の仕組みに完全に満足したことはありません。多くの例外があり、try / catchがテーブルにもたらします(スタックの巻き戻しなど)が、その過程で多くのOOモデルが壊れているようです。
とにかく、ここに問題があります:
ネットワーク化されたファイルIO操作をラップまたは含むクラスがあるとします(たとえば、どこかの特定のUNCパスにあるファイルの読み取りと書き込み)。さまざまな理由で、これらのIO操作を失敗させたくないので、失敗を検出した場合は再試行し、成功するかタイムアウトに達するまで再試行を続けます。私はすでに便利なRetryTimerクラスを持っており、これをインスタンス化して、再試行の間に現在のスレッドをスリープさせ、タイムアウト期間がいつ経過したかなどを判断するために使用できます。
問題は、このクラスのいくつかのメソッドに多数のIO操作があり、それぞれをtry-catch/retryロジックでラップする必要があることです。
コードスニペットの例を次に示します。
RetryTimer fileIORetryTimer = new RetryTimer(TimeSpan.FromHours(10));
bool success = false;
while (!success)
{
try
{
// do some file IO which may succeed or fail
success = true;
}
catch (IOException e)
{
if (fileIORetryTimer.HasExceededRetryTimeout)
{
throw e;
}
fileIORetryTimer.SleepUntilNextRetry();
}
}
では、クラス全体のすべてのファイルIO操作でこのコードのほとんどが重複しないようにするにはどうすればよいでしょうか。私の解決策は、匿名のデリゲートブロックと、渡されたデリゲートブロックを実行するクラスの単一のメソッドを使用することでした。これにより、他の方法でこのようなことができるようになりました。
this.RetryFileIO( delegate()
{
// some code block
} );
私はこれがやや好きですが、それはまだまだ望まれていません。他の人がこのような問題をどのように解決するのか聞きたいです。