15.3 Task 异常

1. 在等待时拆包异常

在等待任务时，任务出错或取消都将抛出异常，但并不是 AggregateException 。大多情况下为方便起见，抛出的是 AggregateException 中的第一个异常，往往这就是我们想要的。异步特性就是像编写同步代码那样编写异步代码，如下所示：

         async Task<string> FetchFirstSuccessfulAsync(IEnumerable<string> urls)

         {

             //验证url

             foreach (string url in urls)

             {

                 try

                 {

                     using (var client=new HttpClient())

                     {

                         return await client.GetStringAsync(url);

                     }

                 }

                 catch (System.Net.WebException)

                 {

                     //记录日志

                 }

             }

             throw new System.Net.WebException("No urls Success");

         }

　　目前，先不要在意损失所有的原始异常，以及按顺序获取所有页面。我想说明的是，我们希望在这里捕获 WebException 。执行一个使用 HttpClient 的异步操作，失败后可抛出 WebException 。我们想捕获并处理它，对吧？但 GetStringAsync() 方法不能为服务器超时等错误抛出 WebException ，因为方法仅仅启动了操作。它只能返回一个包含 WebException 的任务。如果简单地调用该任务的 Wait() 方法，将会抛出一个包含 WebException 的 AggregateException 。任务awaiter的 GetResult 方法将抛出 WebException ，并被以上代码所捕获。　　

当然，这样会丢失信息。如果错误的任务中包含多个异常，则 GetResult 只能抛出其中的一个异常（即第一个）。你可能需要重写以上代码，这样在发生错误时，调用者就可捕获 AggregateException 并检查所有失败的原因。重要的是，一些框架方法（如 Task.WhenAll() ）也可以实现这一点。 WhenAll() 方法可异步等待（方法调用中指定的）多个任务的完成。如果其中有失败的，则结果即为失败，并包含所有错误任务中的异常。但如果只是等待（await） WhenAll() 返回的任务，则只能看到第一个异常。　　

幸好，要解决这个问题并不需要太多的工作。我们可以使用可等待模式的知识，编写一个 Task<T> 的扩展方法，从而创建一个可从任务中抛出原始 AggregateException 的特殊可等待模式成员。以下：

     public static partial class TaskExtensions

     {

         [Description("Listing 15.03")]

         public static AggregatedExceptionAwaitable WithAggregatedExceptions(this Task task)

         {

             if (task == null)

             {

                 throw new ArgumentNullException("task");

             }

             return new AggregatedExceptionAwaitable(task);

         }

         public struct AggregatedExceptionAwaitable

         {

             private readonly Task task;

             internal AggregatedExceptionAwaitable(Task task)

             {

                 this.task = task;

             }

             public AggregatedExceptionAwaiter GetAwaiter()

             {

                 return new AggregatedExceptionAwaiter(task);

             }

         }

         public struct AggregatedExceptionAwaiter : ICriticalNotifyCompletion

         {

             private readonly Task task;

             internal AggregatedExceptionAwaiter(Task task)

             {

                 this.task = task;

             }

             // Delegate most members to the task's awaiter

             public bool IsCompleted { get { return task.GetAwaiter().IsCompleted; } }

             public void UnsafeOnCompleted(Action continuation)

             {

                  task.GetAwaiter().UnsafeOnCompleted(continuation);

             }

             public void OnCompleted(Action continuation)

             {

                 task.GetAwaiter().OnCompleted(continuation);

             }

             public void GetResult()

             {

                 // This will throw AggregateException directly on failure,

                 // unlike task.GetAwaiter().GetResult()

                 task.Wait();

             }

         }

     }

2. 在抛出异常时进行包装

　　你可能已经猜到我要说什么了，没错，就是异步方法在调用时永远不会直接抛出异常。异常方法会返回 Task 或 Task<T> ，方法内抛出的任何异常（包括从其他同步或异步操作中传播过来的异常）都将简单地传递给任务，就像前面介绍的那样。如果调用者直接等待任务，则可得到一个包含真正异常的 AggregateException ；但如果调用者使用 await ，异常则会从任务中解包。返回 void 的异步方法可向原始的 SynchronizationContext 报告异常，如何处理将取决于上下文。　　

　　除非你真的在乎为特定的上下文包装和解包异常，否则只需捕获嵌套的异步方法所抛出的异常即可。

         private async static void MainSync()

         {

             Task<string> task = ReadFileAsync("fileName");

             try

             {

                 string text = await task;

                 Console.WriteLine("file content {0}", text);

             }

             catch (System.IO.IOException ex)

             {

                 Console.WriteLine("caught exception {0}", ex.Message);

             }

         }

         private async static Task<string> ReadFileAsync(string fileName)

         {

             using (var reader = System.IO.File.OpenText(fileName))

             {

                 return await reader.ReadToEndAsync();

             }

         }

　　调用 File.OpenText 时可抛出一个 IOException （除非创建了一个名为“garbage file” 的文件），但如果 ReadToEndAsync 返回的任务失败了，也会出现同样的执行路径。在 MainAsync 中， ReadFileAsync 的调用发生在进入 try 块之前，但只有在等待任务时，调用者才能看到异常并在 catch 块中捕获，就像前面的 WebException 示例一样。同样，除异常发生的时机以外，其行为我们也非常熟悉。

　　与迭代器块类似，参数验证会有些麻烦。假设我们在验证完参数不含有空值后，想在异步方法里做一些处理。如果像在同步代码中那样验证参数，那么在等待任务之前，调用者不会得到任何错误提示。代码清单15-5给出了一个这样的例子。

         static void Main(string[] args)

         {

             MainAsync().Wait();

             Console.ReadKey();

         }

         private async static Task MainAsync()

         {

             Task<int> task = ComputeLengthAsync(null);

             Console.WriteLine("fetch the task");

             int length = await task;

             Console.WriteLine("length {0}", length);

         }

         private async static Task<int> ComputeLengthAsync(string text)

         {

             if (text == null)

             {

                 throw new ArgumentNullException("text");

             }

             await Task.Delay();

             return text.Length;

         }

　　代码清单15-5在失败前会先输出 Fetched the task 。实际上，在输出这条结果之前，异常就已经同步地抛出了，这是因为在验证语句之前并不存在 await 表达式。但调用代码直到等待返回的任务时，才能看到这个异常。一般来说，参数验证无须耗时太久（或导致其他异步操作）。最好能在系统陷入更大的麻烦以前，立即报告失败的存在。例如，如果对 HttpClient. GetStringAsync 传递一个空引用，则其可立即抛出异常。　　

在C# 5中，有两种方式可以迫使异常立即抛出。第一种方式是将参数验证和实现分离，这与代码清单6-9中处理迭代器块的情形相同。以下代码清单展示了 ComputeLengthAsync 的固定版本。

代码清单15-6 将参数验证从异步实现中分离出来

         private static Task<int> ComputeLengthAsync(string text)

         {

             if (text == null)

             {

                 throw new ArgumentNullException("text");

             }

             return ComputeLengthAsyncImpl(text);

         }

         private async static Task<int> ComputeLengthAsyncImpl(string text)

         {

             await Task.Delay();  //模拟真正的异步工作

             return text.Length;

         }

　　在代码清单15-6中，就语言形式而言， ComputeLengthAsync 本身并不是一个异步方法，因为它没有 async 修饰符。该方法执行时使用的是正常的执行流，因此如果方法开始处的参数验证抛出异常，就真的会抛出异常。而如果通过验证，则返回 ComputeLengthAsyncImpl 方法（工作真正发生的地方）创建的任务。在更现实的场景中， ComputeLengthAsync 可以为公共或内部（internal）方法，而 ComputeLengthAsyncImpl 应该为私有方法，因为它假设参数验证已经执行过了。　　

　　另一个及早（eager）验证的方法是使用异步匿名函数，15.4节再来讨论这个示例。　　

　　异步方法中还有一种异常，其处理方式与其他异常不同，这个异常就是：取消（cancellation）。

3. 处理取消

　　任务并行库（TPL）利用 CancellationTokenSource 和 CancellationToken 两种类型向.NET 4中引入了一套统一的取消模型。该模型的理念是，创建一个 CancellationToken Source ，然后向其请求一个 CancellationToken ，并传递给异步操作。可在source上只执行取消操作，但该操作会反映到token上。（这意味着你可以向多个操作传递相同的token，而不用担心它们之间会相互干扰。）取消token有很多种方式，最常用的是调用 ThrowIfCancellation Requested ，如果取消了token，并且没有其他操作，则会抛出 OperationCanceledException 。如果在同步调用（如 Task.Wait ）中执行了取消操作，则可抛出同样的异常。

　　C# 5规范中并没有说明取消操作如何与异步方法交互。根据规范，如果异步方法体抛出任何异常，该方法返回的任务则将处于错误状态。“错误”的确切含义因实现而异，但实际上，如果异步方法抛出 OperationCanceledException （或其派生类，如 TaskCanceled Exception ），则返回的任务最终状态为 Canceled 。以下代码清单证实了导致任务取消的原因确实是一个异常。

         static void Main(string[] args)

         {

             Task task = ThrowCancellationException();

             Console.WriteLine(task.Status);

             Console.ReadKey();

         }

         private async static Task ThrowCancellationException()

         {

             throw new OperationCanceledException();

         }

这段代码的输出为 Canceld ，而不是 Faulted 。如果在任务上执行 Wait() ，或请求其结果（针对 Task<T> ），则 AggregateException 内还是会抛出异常，所以没有必要在每次使用任务时都显式检查是否有取消操作。

　　重要的是，等待一个取消了的操作，将抛出原始的 OperationCanceledException 。这意味着如果不采取一些直接的行动，从异步方法返回的任务同样会被取消，因为取消操作具有可传播性。代码清单15-8给出了一个有关任务取消操作的更为实际的例子。

         static void Main(string[] args)

         {

             var source = new CancellationTokenSource();

             var task = DelayFor30Seconds(source.Token);

             source.CancelAfter(TimeSpan.FromSeconds());

             Console.WriteLine("initial status {0}", task.Status);

             try

             {

                 task.Wait();

             }

             catch (AggregateException ex)

             {

                 Console.WriteLine("caught {0}", ex.InnerExceptions[]);

             }

             Console.WriteLine("final status {0}", task.Status);

             Console.ReadKey();

             /*  waiting for 30 seconds...

             initial status WaitingForActivation

             caught System.Threading.Tasks.TaskCanceledException: 已取消一个任务。

             final status Canceled   */

         }

         static async Task DelayFor30Seconds(CancellationToken token)

         {

             Console.WriteLine("waiting for 30 seconds...");

             await Task.Delay(TimeSpan.FromSeconds(), token);

         }

　　上述代码中启动了一个异步操作，该操作调用 Task.Delay 模拟真正的工作，并提供了一个 CancellationToken 。这一次，我们的确涉及了多个线程：到达 await 表达式时，控制返回到调用方法，这时要求 CancellationToken 在1秒后取消。然后（同步地）等待任务完成，并期望在最终得到一个异常。最后展示任务的状态。

　　可认为取消操作默认是可传递的：如果A操作等待B操作，而B操作被取消了，那么我们认为 A操作也被取消了。当然，你不必这么做。你可以在 DelayFor30Seconds 方法中捕获 OperationCanceled Exception ，然后或继续做其他事情，或立即返回，或干脆抛出一个其他类型的异常。异步特性不会移除控制，它只是提供了一种有用的默认行为而已。

　　【说明】小心使用该代码代码清单15-8在控制台程序中或从线程池线程调用时，均可运作良好。但如果在Windows Forms UI线程（或其他单线程同步上下文）上执行这段代码，则会造成死锁。能看出原因吗？想想在延迟任务完成时， DelayFor30Seconds 方法会试图返回到哪个线程上？再想想 task.Wait() 调用运行在哪个线程上？这是个相对简单的例子，但一些程序员在初次接触异步代码时往往会犯同样的错误。从根本上来说，问题在于调用了 Wait() 方法或 Result 属性。在相关任务完成前，二者均可阻塞线程。我并不是说不能使用它们，但在每次使用时必须考虑清楚。我们应该总是使用 await ，来异步地等待任务的结果。

巴特西

15.3 Task 异常

最新文章

热门文章