5

通常，对于我不希望抛出异常但会抛出异常的代码（即编程错误），我希望我的应用程序崩溃（这样它就不会损坏数据、向用户报告无效数据等）。

使用时是否有获得（接近）这种行为的最佳实践Tasks？我们已经为TaskScheduler.UnobservedTaskException. 问题是这可能比导致意外异常的时间晚得多。

问题： 如果有的话，我应该使用哪个选项：

  1. 我应该将我Task的 s 操作包装在 try/catch 中，并在 catch 中升级我不期望的异常吗？如果是这样，我应该怎么做才能升级（即我想让它触发AppDomain.UnhandledException事件并终止。

  2. 我是否应该OnlyOnFaulted在 ui 线程（这是一个 Winforms 应用程序）上附加一个延续（），如果它不是预期的异常，它会重新引发异常？

  3. 有更好或更标准的方法吗？

这是＃1的样子：

var t1 = Task.Factory.StartNew(() =>
    {
        try
        {
            string path = null; // Programming error.  Should have been a valid string.  Will cause System.ArgumentNullException below
            using (FileStream fs = File.Create(path))
            {

            }
        }
        catch (System.IO.IOException) { throw; } // Expected possible exception
        catch (System.UnauthorizedAccessException) { throw; }
        catch
        {
            // Anything caught here is not an expected exception and should be escalated.
            // But how?
        }
    });

这是＃2的样子：

TaskScheduler uiTaskScheduler = TaskScheduler.FromCurrentSynchronizationContext();
var t1 = Task.Factory.StartNew(() =>
    {
        string path = null; // Programming error.  Should have been a valid string.  Will cause System.ArgumentNullException below
        using (FileStream fs = File.Create(path))
        {

        }
    });

t1.ContinueWith(t =>
    {
        Exception ex = t.Exception;
        if (ex is IOException || ex is UnauthorizedAccessException) // Expected exceptions (do nothing)
            return;

        throw ex; // Not expected (escalate by rethrowing)

    }, CancellationToken.None, TaskContinuationOptions.OnlyOnFaulted, uiTaskScheduler);
4

1 回答 1

2

附加一个延续对我来说是一个很好的方法。如果您对不会因为其他原因阻塞 UI 线程太久的假设感到满意，那么强制继续在 UI 线程上运行对我来说似乎是一个非常合理的选择。这样，您也可以执行任何您需要的 UI 任务，作为紧急关机的一部分。

于 2013-05-17T18:59:03.040 回答