标签：
建议85：Task中的异常处理
在任何时候，异常处理都是非常重要的一个环节。多线程与并行编程中尤其是这样。如果不处理这些后台任务中的异常，应用程序将会莫名其妙的退出。处理那些不是主线程（如果是窗体程序，那就是UI主线程）产生的异常，最终的办法都是将其包装到主线程上。
在任务并行库中，如果对任务运行Wait、WaitAny、WaitAll等方法，或者求Result属性，都能捕获到AggregateException异常。可以将AggregateException异常看做是任务并行库编程中最上层的异常。在任务中捕获的异常，最终都应该包装到AggregateException中。一个任务并行库异常的简单处理示例如下：
static void Main(string[] args) { Task t = new Task(() => { throw new Exception("任务并行编码中产生的未知异常"); }); t.Start(); try { //若有Result，可求Result t.Wait(); } catch (AggregateException e) { foreach (var item in e.InnerExceptions) { Console.WriteLine("异常类型：{0}{1}来自：{2}{3}异常内容：{4}", item.GetType(), Environment.NewLine, item.Source, Environment.NewLine, item.Message); } } Console.WriteLine("主线程马上结束"); Console.ReadKey(); }
上面的代码输出：
异常类型：System.Exception
来自：ConsoleApplication3
异常内容：任务并行编码中产生的未知异常
主线程马上结束
大家也许已经注意到，虽然运行Wait、WaitAny、WaitAll方法，或者求Result属性能得到任务的异常信息，但是这会阻滞当前线程。这往往不是我们所希望看到的，岂能为了得到一个异常就故意等待？这时可以考虑任务并行库中Task类型的一个功能：新起一个后续任务，就可以解决等待的问题：
static void Main() { Task t = new Task(() => { throw new Exception("任务并行编码中产生的未知异常"); }); t.Start(); Task ttEnd = t.ContinueWith((task) => { foreach (Exception item in task.Exception.InnerExceptions) { Console.WriteLine("异常类型：{0}{1}来自：{2}{3}异常内容：{4}", item.GetType(), Environment.NewLine, item.Source, Environment.NewLine, item.Message); } }, TaskContinuationOptions.OnlyOnFaulted); Console.WriteLine("主线程马上结束"); Console.ReadKey(); }
输出为：
主线程马上结束
异常类型：System.Exception
来自：ConsoleApplication3
异常内容：任务并行编码中产生的未知异常
以上方法解决了主线程等待的问题，但是仔细研究我们会发现，异常处理没有回到主线程中，它还是在线程池中。在某些场合，比如对于业务逻辑上特定异常的处理，需要采取这种方式，而且我们也鼓励这种用法。但很明显，更多时候我们还需要更进一步将异常处理封装到主线程。
Task没有提供将任务中的异常包装到主线程的接口。一个可行的办法是，仍旧使用类似Wait的方法来达到此目的。在本建议一开始的代码中，我们对于主工作任务采用Wait的方法，这是不可取的。因为主工作任务也许会持续一段较长的时间，那样会阻塞调用者，并让调用者觉得不能忍受。而本建议的第二段代码中，新任务只完成了处理异常，这意味着新任务不会延续较长时间，所以，在这个新任务上维持等待对于调用者来说，是可以忍受的。所以，我们可以采用这个方法将异常包装到主线程中：
static void Main(string[] args) { Task t = new Task(() => { throw new InvalidOperationException("任务并行编码中产生的未知异常"); }); t.Start(); Task ttEnd = t.ContinueWith((task) => { throw task.Exception; }, TaskContinuationOptions.OnlyOnFaulted); try { tEnd.Wait(); } catch (AggregateException err) { foreach (var item in err.InnerExceptions) { Console.WriteLine("异常类型：{0}{1}来自： {2}{3}异常内容：{4}", item.InnerException.GetType(), Environment.NewLine, item.InnerException.Source, Environment.NewLine, item.InnerException.Message); } } Console.WriteLine("主线程马上结束"); Console.ReadKey(); }
输出为：
异常类型：System.InvalidOperationException
来自：ConsoleApplication3
异常内容：任务并行编码中产生的未知异常
主线程马上结束
故事并没有到此结束。
对线程调用Wait方法（或者求Result）不是最好的办法，因为它会阻滞主线程，并且CLR在后台会新起线程池线程来完成额外的工作。如果要包装异常到主线程，另外一个方法就是使用事件通知的方式：
static event EventHandler<AggregateExceptionArgs> AggregateExceptionCatched; public class AggregateExceptionArgs: EventArgs { public AggregateException AggregateException{ get; set; } } static void Main(string[] args) { AggregateExceptionCatched += EventHandler<AggregateExceptionArgs>(Program_AggregateExceptionCatched); Task t = new Task(() => { try { throw new InvalidOperationException("任务并行编码中产生的未知异常"); } catch (Exception err) { AggregateExceptionArgs errArgs = new AggregateExceptionArgs() { AggregateException = new AggregateException(err) }; AggregateExceptionCatched(null, errArgs); } }); t.Start(); Console.WriteLine("主线程马上结束"); Console.ReadKey(); } static void Program_AggregateExceptionCatched(object sender, AggregateExceptionArgs e) { foreach (var item in e.AggregateException.InnerExceptions) { Console.WriteLine("异常类型：{0}{1}来自：{2}{3}异常内容：{4}", item.GetType(), Environment.NewLine, item.Source, Environment.NewLine, item.Message); } }
在这个例子中，我们声明了一个委托AggregateExceptionCatchHandler，它接受两个参数，一个是事件的通知者；另一个是事件变量AggregateExceptionArgs。AggregateExceptionArgs是为了包装异常而新建的一个类型。在主线程中，我们为事件AggregateExceptionCatched分配了事件处理方法Program_AggregateExceptionCatched，当任务Task捕获到异常时，代码引发事件。
这种方式完全没有阻滞主线程。如果是在Winform或WPF窗体程序中，要在事件处理方法中处理UI界面，还可以将异常信息交给窗体的线程模型去处理。所以，最终建议大家采用事件通知的模型处理Task中的异常。
注意 任务调度器TaskScheduler提供了这样一个功能，它有一个静态事件用于处理未捕获到的异常。一般不建议这样使用，因为事件回调是在进行垃圾回收的时候才发生的。如下：
static void Main() { TaskScheduler.UnobservedTaskException += new EventHandler< UnobservedTaskExceptionEventArgs>(TaskScheduler_UnobservedTaskException); Task t = new Task(() => { throw new Exception("任务并行编码中产生的未知异常"); }); t.Start(); Console.ReadKey(); t.Dispose(); t = null; //GC.Collect(0); Console.WriteLine("主线程马上结束"); Console.ReadKey(); } static void TaskScheduler_UnobservedTaskException(object sender, UnobservedTaskExceptionEventArgs e) { foreach (Exception item in e.Exception.InnerExceptions) { Console.WriteLine("异常类型：{0}{1}来自：{2}{3}异常内容：{4}", item.GetType(), Environment.NewLine, item.Source, Environment.NewLine, item.Message); } //将异常标识为已经观察到 e.SetObserved(); }
上面的这段代码运行的结果中并不会输出异常信息，因为发生异常的时刻，并没有发生垃圾回收（垃圾回收时机由CLR决定）。必须要将GC.Collect(0)的注释去掉，强制执行垃圾回收，才会观察到异常信息。这也正是此种方式的局限性。
转自：《编写高质量代码改善C#程序的157个建议》陆敏技
编写高质量代码改善C#程序的157个建议——建议85：Task中的异常处理
标签：
原文地址：http://www.cnblogs.com/jesselzj/p/4743456.html
