码农还怕这个？码农的工作充满了各种选择和balance

c++的异常相比java、c#之类的异常难于普及，肯定是有原因的。

机翻一下28楼链接里的分析：

使用异常

另外一个处理错误的选择是显而易见的！就是使用异常。当然，如果你可以的话。它们并不在所有不同的环境中都允许使用，有些团队禁止使用它们。

在某种意义上，这是一个有争议的话题，因为人们对异常可能有非常坚定的看法，很多书籍和会议演讲都可以围绕异常来展开，也确实有很多这样做的。

有些人认为它们代价高昂。像往常一样，这取决于情况。如果你大部分时间都在从数据库读取数据或通过网络发送数据，那么这就没有那么重要了。

另一方面，始终为真的是，它完全绕过了正常的控制流程，使用异常的代码是非常难以推理的。通常你看不到，或者很难看到从你开始的地方结束在哪里。很多人误用异常，多次记录错误并且继续抛出异常。

我认为唯一能让它运行良好的方式是，如果你有一个明确陈述在文档中的异常处理策略。即便如此，也有很大的可能性会不被遵守。尤其是在大型公司中，员工总是变来变去。

【 在 chunhui 的大作中提到: 】
: 考虑什么情况下需要和不需要是一种负担。考虑错了，全白搭。
--
修改:z16166 FROM 222.128.162.*
FROM 222.128.162.*

既不测试，也不反汇编分析，更不查资料，就这么怀疑，符合“人们对异常可能有非常坚定的看法”这个描述，只不过是无根据的"坚定"，俗称“无脑顽固派”

【 在 lwp 的大作中提到: 】
: 不抛异常性能往下掉是你测试测出来的结论？
: :
--
FROM 222.128.162.*

32位x86也可以按x64这么设计，不过因为32位ABI当时就那么定了，得用代码动态建立exception handler chain。

转一个比较：www dot osronline dot com /article.cfm%5earticle=469.htm

因为在 x86 上，每个使用 SEH 的函数都将上述结构作为其序言的一部分，所以据说 x86 使用基于帧的异常处理。这种方法有几个问题：

由于异常信息存储在堆栈上，因此很容易受到缓冲区溢出攻击。

高开销。异常就是异常，这意味着在常见情况下不会发生异常。无论如何，每次输入使用 SEH 的函数时，都会执行这些额外的指令。

由于 x64 是一个消除数十年来许多弊端的机会，SEH 进行了彻底改革，解决了上述两个问题。在 x64 上，SEH 已经变成基于表的，这意味着在编译源代码时，会创建一个表来完整描述模块内的所有异常处理代码。然后将该表存储为 PE 标头的一部分。如果发生异常，Windows将解析异常表以找到合适的异常处理程序来执行。由于异常处理信息安全地隐藏在 PE 标头中，因此它不再容易受到缓冲区溢出攻击。此外，由于异常表是作为编译过程的一部分生成的，因此在正常处理期间不会产生运行时开销（以push和pop指令的形式）。

当然，基于表的异常处理方案本身也有一些负面影响。例如，基于表的方案往往比基于堆栈的方案占用更多的内存空间。此外，虽然正常执行路径中的开销减少了，但处理异常所需的开销明显高于基于帧的方法。与生活中的一切一样，在评估基于表的异常处理方法还是基于帧的异常处理方法是否“最佳”时，需要考虑权衡。

【 在 hgoldfish 的大作中提到: 】
: 也就是说这个是 windows 针对 PE 格式的特殊规定。
: 32 位不支持纯粹只是因为 32 位 windows 不支持，而不是因为什么处理器的限制是吧？
:
--
FROM 222.128.162.*

这不是个对错问题，而只是个flavor或者说paradigm问题。
根据自己的balance标准决定怎么搞。cpp大佬包括cpp他爹B.S，都是推荐用异常。
但要防止滥用异常，人多时这个并不一定好解决。

而且，为什么死盯着cpp的异常，认为它开销高、烂，而不认为java/c#/python/js等的异常开销高、烂呢？

【 在 overcomeunic 的大作中提到: 】
: 别整没用的
: 将一个string转换成int32，抛异常，你觉得是对 还是 不对
:
--
修改:z16166 FROM 222.128.162.*
FROM 222.128.162.*

看来你已经被cpp f**k得太多了，以至于辩不过要来这种方式了

【 在 overcomeunic 的大作中提到: 】
: 那还说啥呀
: 如果这么基础的一个函数 抛异常，你是用 还是 不用
: 那还是被FUCK得少了啊，FUCK多了嘴就不硬了
--
FROM 222.128.162.*