建议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}来自:
{}{}异常内容:{}", 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中的异常处理的更多相关文章

  1. 编写高质量代码改善C#程序的157个建议[1-3]

    原文:编写高质量代码改善C#程序的157个建议[1-3] 前言 本文主要来学习记录前三个建议. 建议1.正确操作字符串 建议2.使用默认转型方法 建议3.区别对待强制转换与as和is 其中有很多需要理 ...

  2. 读书--编写高质量代码 改善C#程序的157个建议

    最近读了陆敏技写的一本书<<编写高质量代码  改善C#程序的157个建议>>书写的很好.我还看了他的博客http://www.cnblogs.com/luminji . 前面部 ...

  3. 编写高质量代码改善C#程序的157个建议——建议157:从写第一个界面开始,就进行自动化测试

    建议157:从写第一个界面开始,就进行自动化测试 如果说单元测试是白盒测试,那么自动化测试就是黑盒测试.黑盒测试要求捕捉界面上的控件句柄,并对其进行编码,以达到模拟人工操作的目的.具体的自动化测试请学 ...

  4. 编写高质量代码改善C#程序的157个建议——建议156:利用特性为应用程序提供多个版本

    建议156:利用特性为应用程序提供多个版本 基于如下理由,需要为应用程序提供多个版本: 应用程序有体验版和完整功能版. 应用程序在迭代过程中需要屏蔽一些不成熟的功能. 假设我们的应用程序共有两类功能: ...

  5. 编写高质量代码改善C#程序的157个建议——建议155:随生产代码一起提交单元测试代码

    建议155:随生产代码一起提交单元测试代码 首先提出一个问题:我们害怕修改代码吗?是否曾经无数次面对乱糟糟的代码,下决心进行重构,然后在一个月后的某个周一,却收到来自测试版的报告:新的版本,没有之前的 ...

  6. 编写高质量代码改善C#程序的157个建议——建议154:不要过度设计,在敏捷中体会重构的乐趣

    建议154:不要过度设计,在敏捷中体会重构的乐趣 有时候,我们不得不随时更改软件的设计: 如果项目是针对某个大型机构的,不同级别的软件使用者,会提出不同的需求,或者随着关键岗位人员的更替,需求也会随个 ...

  7. 编写高质量代码改善C#程序的157个建议——建议153:若抛出异常,则必须要注释

    建议153:若抛出异常,则必须要注释 有一种必须加注释的场景,即使异常.如果API抛出异常,则必须给出注释.调用者必须通过注释才能知道如何处理那些专有的异常.通常,即便良好的命名也不可能告诉我们方法会 ...

  8. 编写高质量代码改善C#程序的157个建议——建议152:最少,甚至是不要注释

    建议152:最少,甚至是不要注释 以往,我们在代码中不写上几行注释,就会被认为是钟不负责任的态度.现在,这种观点正在改变.试想,如果我们所有的命名全部采用有意义的单词或词组,注释还有多少存在的价值. ...

  9. 编写高质量代码改善C#程序的157个建议——建议151:使用事件访问器替换公开的事件成员变量

    建议151:使用事件访问器替换公开的事件成员变量 事件访问器包含两部分内容:添加访问器和删除访问器.如果涉及公开的事件字段,应该始终使用事件访问器.代码如下所示: class SampleClass ...

  10. 编写高质量代码改善C#程序的157个建议——建议150:使用匿名方法、Lambda表达式代替方法

    建议150:使用匿名方法.Lambda表达式代替方法 方法体如果过小(如小于3行),专门为此定义一个方法就会显得过于繁琐.比如: static void SampeMethod() { List< ...

随机推荐

  1. 在使用Ajax请求返回json数据的时候IE浏览器弹出下载保存对话框的解决方法

    在使用Ajax请求返回json数据的时候IE浏览器弹出下载保存对话框的解决方法 最近在做一个小东西,使用kindeditor上传图片的时候,自己写了一个上传的方法,按照协议规则通过ajax返回json ...

  2. Asp.net mvc 限制路由参数类型

    routes.MapRoute(                "Activity2", // 路由名称                "Activity/{id}&qu ...

  3. Java int Integer

    http://www.cnblogs.com/haimingwey/archive/2012/04/16/2451813.html http://developer.51cto.com/art/200 ...

  4. 「小程序JAVA实战」小程序我的个人信息-注销功能(42)

    转自:https://idig8.com/2018/09/06/xiaochengxujavashizhanxiaochengxuwodegerenxinxi-zhuxiaogongneng40/ 注 ...

  5. 获取properties配置

    1.      使用@Value @Value("${swagger.enable}") 使用Spring的PropertyPlaceholderConfigurer关联 @Val ...

  6. 批处理文件中获取当前所在路径的几种方法,以及写文件到txt

    @echo off setlocal EnableDelayedExpansion echo 当前正在运行的批处理文件所在路径:!cd! pause @echo off echo 当前目录是:%cd% ...

  7. AOP的MethodBeforeAdvice

    使用Spring自动生成代理类,spring利用的是动态代理机制 接口 Java代码 public interface UserDao { void addUser(); void deleteUse ...

  8. Go语言的基本类型转换-golang类型转换

    简单整理一下Golang的基本类型转换,作为备忘: 1.整形到字符串: var i int = 1 var s string 3.  s = strconv.Itoa(i) 或者 s = Format ...

  9. C++11之 auto

    [C++11类型推导] 1.使用auto的时候,编译器根据上下文情况,确定auto变量的真正类型.auto在C++14中可以作为函数的返回值,因此auto AddTest(int a, int b)的 ...

  10. kali linux: 网卡监听及扫描网络

    一.网卡监听: kali不支持内置网卡,仅仅支持usb网卡.我用的虚拟机.首先在虚拟机的可移动设备里打开usb网卡的连接,执行ifconfig命令,如下: eth0接口是本地有线网卡信息,lo接口是本 ...