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

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

要不要异常和错误分开，和 php 那样
【 在 adoal 的大作中提到: 】
: C++的发展过程中，引入了多种不同编程范式，同时为了保有老用户
: 和业界积累的老资产，坚持对历史全兼容，坚决不抛弃plain C的东西，
: 也不抛弃pre-modern C++时代的东西，包括语法和历史上的标准库。
: ...................
--
FROM 223.198.80.*

跟ABI有关

MS针对x64规定了一套ABI，把异常处理的信息静态存储在64位PE文件的IMAGE_DIRECTORY_ENTRY_EXCEPTION这个位置的表里，里面有unwind chain。一般是编译器负责生成这个表。

发生异常时（比如调用RaiseException()这个OS API来抛出异常），OS可以根据这个表进行异常派发，然后可以调用和语言相关的异常处理程序，比如C++的__CxxFrameHandler3、__CxxFrameHandler4等。

自己手写汇编代码的话，只要遵循这个ABI，也是可以正常处理异常的。

JIT动态生成的代码的话，有对应的OS API RtlInstallFunctionTableCallback()/RtlAddFunctionTable()可以动态注册异常处理信息。

ARM32 ABI和32-bit x86差不多，都是用代码动态生成SEH链。

ARM64 ABI和x64差不多。

还有一个ARM64EC ABI，用于ARM64和x64的交互，win11 on arm用的。

【 在 hgoldfish 的大作中提到: 】
: 为啥 amd64 架构能做到这样。是 CPU 特别处理的吗？
: arm32 和 arm64 有没有这样的区别？
:
--
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.*

这个异常的处理应该像cpu的分支预测，程序员在编程时就应该预测最可能的路径，不可
能持续抛异常



【 在 overcomeunic 的大作中提到: 】
: 推荐个毛线
: 但凡持续抛异常，性能掉到底
--
FROM 223.104.63.*