Chinaunix首页 | 论坛 | 博客
  • 博客访问: 285169
  • 博文数量: 65
  • 博客积分: 3091
  • 博客等级: 中校
  • 技术积分: 705
  • 用 户 组: 普通用户
  • 注册时间: 2005-01-25 09:44
文章存档

2013年(2)

2012年(11)

2011年(12)

2010年(13)

2009年(15)

2008年(12)

分类: C/C++

2008-08-05 17:02:19

SJLJ 异常处理方法(EH: exception handling)是一种使用 setjump() 和 longjump() 来回滚运行时程序栈的方法。MinGW 的官方发布中采用了 SJLJ 作为异常处理的标准实现,因为它在各种情况下都运行的比较可靠。但它的一大缺点是运行效率格外差。因此我推荐在GCC中使用 DWARF2 异常处理方法。值得注意的一个限制条件是,使用 DWARF2 实现方法编译的代码中引发的异常不能传播到使用其他的异常处理实现方法所编译的代码中去。例如:某个回调函数引发了一个异常并且它没有处理这个异常,而是将异常回传给了调用这个回调函数的 Windows DLL(可能在主消息循环中接收),那么就会发生问题。我个人认为这个限制并不是什么大不了的问题,因为只要添加代码处理这个异常而不让它外传就可以了。因为 SJLJ 的实现方法其性能实在太差,所以我倾向于使用 DWARF2 的异常处理方法。

参见:
SJLJ EH (exception handling) is a method of unwinding the stack that uses setjump() and longjump(). SJLJ EH is the official standard on MinGW, because it works reliably in all cases, but it has the disadvantage of being tremendously inefficient. For that reason, I recommend you use gcc with DWARF2 EH (exception handling). However, there there is a limitation of DWARF2 EH that you need to be aware of - which is that an exception thrown inside code compiled with DWARF2 EH cannot propagate through any code that was not compiled with DWARF2 EH. For an example of that, consider the case where an exception is thrown from inside a callback, and the exception isn't caught from inside the callback, but instead propagates back up to the Windows DLL that invoked the callback (perhaps to be caught inside the main message loop). I personally don't find this limitation to be a problem, unlike the severely poor performance of SJLJ EH.
阅读(4596) | 评论(0) | 转发(1) |
给主人留下些什么吧!~~