为何编译器无法优化try-catch块中的单个throw语句？

你观察到的现象本质是C++标准对可观察行为的要求，以及编译器优化的边界限制，具体原因如下：

1. throw操作存在不可忽略的副作用 #

throw 10并非无意义的操作：它会触发C++运行时的完整异常流程，包括：

• 调用__cxa_allocate_exception分配异常对象内存
• 触发栈展开（即使当前代码没有需要析构的对象，编译器不能假设所有场景都如此）
• 进入catch块后调用__cxa_begin_catch和__cxa_end_catch完成异常处理

根据C++标准，这些流程中涉及的操作（比如栈展开时的析构函数调用）属于可观察行为，编译器必须保证它们被执行，除非能100%证明这些操作没有任何副作用。你的示例代码里虽然没有析构逻辑，但编译器不会为这种极端场景单独开优化特例——毕竟真实代码中throw后的栈展开几乎都有实际作用。

2. 第一段代码能被优化的原因 #

第一段try块里只有int x{10};，这是完全不会抛出异常的操作（int构造不会抛异常）。编译器可以明确判断：这个try/catch块从不会触发异常处理，也没有任何可观察行为，因此可以安全地把整个块优化掉，只保留return 0;的逻辑。

对比两段代码的编译结果 #

第一段代码（无throw） #

int main() {
    try {
        int x{ 10 };
    }
    catch (...) {
    }

    return 0;
}

编译后的汇编：

main:
        xor     eax, eax
        ret

第二段代码（含throw） #

int main() {
    try {
        throw 10;
    }
    catch (...) {
    }

    return 0;
}

编译后的汇编：

main:
        push    rcx
        mov     edi, 4
        call    __cxa_allocate_exception
        xor     edx, edx
        mov     esi, OFFSET FLAT:_ZTIi
        mov     DWORD PTR [rax], 10
        mov     rdi, rax
        call    __cxa_throw
        mov     rdi, rax
        call    __cxa_begin_catch
        call    __cxa_end_catch
        xor     eax, eax
        pop     rdx
        ret

3. 编译器的优化保守性 #

编译器的优化逻辑会优先保证标准合规性，其次才是性能。对于throw+空catch的场景，虽然从最终输出看和直接return 0一致，但中间的异常处理流程是标准要求必须执行的。除非你用特定的编译选项（比如-fno-exceptions关闭异常支持），否则编译器不会跳过这些步骤。

内容的提问来源于stack exchange，提问作者Joel