さまざまな OS での応答をテストしているときに、winForms アプリケーションで奇妙な動作が発生します。
unhandledAggregateException
がスローされる (XP 32 ビット マシンでテストした場合) 長時間実行される操作は、WCF (使用basicHttpBinding
およびStreamed
転送モード) クライアント更新手順の一部です。構造は、次のコード スニペットに似ています。わかりやすくするために、WCF 例外処理を省略しました。
var tsUIthread = TaskScheduler.FromCurrentSynchronizationContext();
int filesCount = 0;
List<MessageContract> files;
private void Update()
{
var cTokenDownloadFiles = new CancellationTokenSource();
var cTokenUpdateDatabases = new CancellationTokenSource();
var task1CheckForNewFiles = Task.Factory.StartNew(() =>
{
filesCount = proxy.GetFiles();
If(filesCount == 0)
{
cTokenDownloadFiles.Cancel();
cTokenUpdateDatabases.Cancel();
}
else
files = new List<MessageContract>();
});
var task2UpdateControls = task1CheckForNewFiles.ContinueWith(result =>
{
UpdateControlsBeforeDownload();
}, CancellationToken.None, TaskContinuationOptions.None, tsUIthread);
var task3DownloadFiles = task2.ContinueWith(result =>
{
for(int i = 0; i< filesCount; i++)
{
try
{
files.Add(proxy.DownloadFile());
}
catch(IOException)
{
cTokenUpdateDatabases.Cancel();
Task.Factory.StartNew(() => ResetControls,
CancellationToken.None, TaskCreationOptions.None, tsUIthread);
retryUpdateTimer.Start(); // System.Windows.Forms.Timer
return;
}
}
}, cTokenDownloadFiles.Token);
var task4UpdateDatabases = task3DownloadFiles.ContinueWith(result =>
{
UpdateDatabases();
},cTokenUpdateDatabases.Token);
var task5UpdateControls = task4UpdateDatabases.ContinueWith(result =>
{
UpdateControlsOnUpdateFinished();
}, CancellationToken.None, TaskContinuationOptions.None, tsUIthread);
}
proxy.DownloadFile()
メソッドを try-catch ブロックでラップしていることに気付くでしょうIO.IOException
。投稿の冒頭で述べたように、私の WCF サービスは のStreamed
転送モードを使用するbasicHttpBinding
ため、何らかの理由で操作の開始後にサーバーへの接続が失われたときに、このタイプの例外をキャッチする必要があります。catch ステートメントで行うことは、データベース更新タスクをキャンセルし、UI コントロールをプライマリ値にリセットしInterval
、数秒でSystem.Windows.Forms.Timer を開始しUpdate()
て、クライアントがインターネットに接続している場合にメソッドを再度実行することだけです。接続性。
この手順全体は、IOException
がスローされたときに開発環境 (Windows7 32 ビット マシン) で期待どおりに機能しますが、Windows XP 32 ビット マシンで winforms アプリケーションをテストすると、未処理AggregateException
の atSystem.Threading.Tasks.ExceptionHolder.Finalize()
によってアプリケーションが終了します。
誰かが似たようなことを経験しましたか? XP マシンでのみ例外がスローされる可能性はありますか? 他の環境ではまだテストしていません。実際のコードには、より多くのタスクと継続が含まれており、下流のビジネス コンポーネントを呼び出しています。継続スパゲッティを使用したタスクの例外処理に関しては、私はちょっと迷っています。例外処理をどのように構築すべきか、いくつかの例を教えていただけますか?