我决定用一小段C++代码和一个有点旧的Linux安装来实际查看生成的代码，而不是猜测。

class MyException
{
public:
    MyException() { }
    ~MyException() { }
};

void my_throwing_function(bool throwit)
{
    if (throwit)
        throw MyException();
}

void another_function();
void log(unsigned count);

void my_catching_function()
{
    log(0);
    try
    {
        log(1);
        another_function();
        log(2);
    }
    catch (const MyException& e)
    {
        log(3);
    }
    log(4);
}

我用g++ -m32 -W -Wall -O3 -save-temps -c编译了它，并查看了生成的汇编文件。

.file   "foo.cpp"
    .section    .text._ZN11MyExceptionD1Ev,"axG",@progbits,_ZN11MyExceptionD1Ev,comdat
    .align 2
    .p2align 4,,15
    .weak   _ZN11MyExceptionD1Ev
    .type   _ZN11MyExceptionD1Ev, @function
_ZN11MyExceptionD1Ev:
.LFB7:
    pushl   %ebp
.LCFI0:
    movl    %esp, %ebp
.LCFI1:
    popl    %ebp
    ret
.LFE7:
    .size   _ZN11MyExceptionD1Ev, .-_ZN11MyExceptionD1Ev

_ZN11MyExceptionD1Ev是MyException::~MyException()，因此编译器决定需要析构函数的非内联副本。

.globl __gxx_personality_v0
.globl _Unwind_Resume
    .text
    .align 2
    .p2align 4,,15
.globl _Z20my_catching_functionv
    .type   _Z20my_catching_functionv, @function
_Z20my_catching_functionv:
.LFB9:
    pushl   %ebp
.LCFI2:
    movl    %esp, %ebp
.LCFI3:
    pushl   %ebx
.LCFI4:
    subl    $20, %esp
.LCFI5:
    movl    $0, (%esp)
.LEHB0:
    call    _Z3logj
.LEHE0:
    movl    $1, (%esp)
.LEHB1:
    call    _Z3logj
    call    _Z16another_functionv
    movl    $2, (%esp)
    call    _Z3logj
.LEHE1:
.L5:
    movl    $4, (%esp)
.LEHB2:
    call    _Z3logj
    addl    $20, %esp
    popl    %ebx
    popl    %ebp
    ret
.L12:
    subl    $1, %edx
    movl    %eax, %ebx
    je  .L16
.L14:
    movl    %ebx, (%esp)
    call    _Unwind_Resume
.LEHE2:
.L16:
.L6:
    movl    %eax, (%esp)
    call    __cxa_begin_catch
    movl    $3, (%esp)
.LEHB3:
    call    _Z3logj
.LEHE3:
    call    __cxa_end_catch
    .p2align 4,,3
    jmp .L5
.L11:
.L8:
    movl    %eax, %ebx
    .p2align 4,,6
    call    __cxa_end_catch
    .p2align 4,,6
    jmp .L14
.LFE9:
    .size   _Z20my_catching_functionv, .-_Z20my_catching_functionv
    .section    .gcc_except_table,"a",@progbits
    .align 4
.LLSDA9:
    .byte   0xff
    .byte   0x0
    .uleb128 .LLSDATT9-.LLSDATTD9
.LLSDATTD9:
    .byte   0x1
    .uleb128 .LLSDACSE9-.LLSDACSB9
.LLSDACSB9:
    .uleb128 .LEHB0-.LFB9
    .uleb128 .LEHE0-.LEHB0
    .uleb128 0x0
    .uleb128 0x0
    .uleb128 .LEHB1-.LFB9
    .uleb128 .LEHE1-.LEHB1
    .uleb128 .L12-.LFB9
    .uleb128 0x1
    .uleb128 .LEHB2-.LFB9
    .uleb128 .LEHE2-.LEHB2
    .uleb128 0x0
    .uleb128 0x0
    .uleb128 .LEHB3-.LFB9
    .uleb128 .LEHE3-.LEHB3
    .uleb128 .L11-.LFB9
    .uleb128 0x0
.LLSDACSE9:
    .byte   0x1
    .byte   0x0
    .align 4
    .long   _ZTI11MyException
.LLSDATT9:

令人惊讶的是！在正常的代码路径上根本没有额外的指令。相反，编译器生成了额外的外部修复代码块，通过函数末尾的表引用（实际上放在可执行文件的单独部分）。所有工作都是由标准库基于这些表（_ZTI11MyException是typeinfo for MyException）在后台完成的。
好吧，这对我来说并不奇怪，我已经知道这个编译器是怎么做的了。继续看汇编输出：

.text
    .align 2
    .p2align 4,,15
.globl _Z20my_throwing_functionb
    .type   _Z20my_throwing_functionb, @function
_Z20my_throwing_functionb:
.LFB8:
    pushl   %ebp
.LCFI6:
    movl    %esp, %ebp
.LCFI7:
    subl    $24, %esp
.LCFI8:
    cmpb    $0, 8(%ebp)
    jne .L21
    leave
    ret
.L21:
    movl    $1, (%esp)
    call    __cxa_allocate_exception
    movl    $_ZN11MyExceptionD1Ev, 8(%esp)
    movl    $_ZTI11MyException, 4(%esp)
    movl    %eax, (%esp)
    call    __cxa_throw
.LFE8:
    .size   _Z20my_throwing_functionb, .-_Z20my_throwing_functionb

这里我们看到了抛出异常的代码。虽然不会因为可能抛出异常而产生额外的开销，但实际抛出和捕获异常显然会产生大量开销。大部分开销隐藏在__cxa_throw中，__cxa_throw必须：

• 在异常表的帮助下遍历堆栈，直到找到该异常的处理程序。
• 展开堆栈，直到它到达那个处理程序。
• 打电话给联络人。

将其与简单返回一个值的成本进行比较，您就会明白为什么异常应该只用于异常返回。
最后，程序集文件的其余部分：

.weak   _ZTI11MyException
    .section    .rodata._ZTI11MyException,"aG",@progbits,_ZTI11MyException,comdat
    .align 4
    .type   _ZTI11MyException, @object
    .size   _ZTI11MyException, 8
_ZTI11MyException:
    .long   _ZTVN10__cxxabiv117__class_type_infoE+8
    .long   _ZTS11MyException
    .weak   _ZTS11MyException
    .section    .rodata._ZTS11MyException,"aG",@progbits,_ZTS11MyException,comdat
    .type   _ZTS11MyException, @object
    .size   _ZTS11MyException, 14
_ZTS11MyException:
    .string "11MyException"

类型信息数据。

.section    .eh_frame,"a",@progbits
.Lframe1:
    .long   .LECIE1-.LSCIE1
.LSCIE1:
    .long   0x0
    .byte   0x1
    .string "zPL"
    .uleb128 0x1
    .sleb128 -4
    .byte   0x8
    .uleb128 0x6
    .byte   0x0
    .long   __gxx_personality_v0
    .byte   0x0
    .byte   0xc
    .uleb128 0x4
    .uleb128 0x4
    .byte   0x88
    .uleb128 0x1
    .align 4
.LECIE1:
.LSFDE3:
    .long   .LEFDE3-.LASFDE3
.LASFDE3:
    .long   .LASFDE3-.Lframe1
    .long   .LFB9
    .long   .LFE9-.LFB9
    .uleb128 0x4
    .long   .LLSDA9
    .byte   0x4
    .long   .LCFI2-.LFB9
    .byte   0xe
    .uleb128 0x8
    .byte   0x85
    .uleb128 0x2
    .byte   0x4
    .long   .LCFI3-.LCFI2
    .byte   0xd
    .uleb128 0x5
    .byte   0x4
    .long   .LCFI5-.LCFI3
    .byte   0x83
    .uleb128 0x3
    .align 4
.LEFDE3:
.LSFDE5:
    .long   .LEFDE5-.LASFDE5
.LASFDE5:
    .long   .LASFDE5-.Lframe1
    .long   .LFB8
    .long   .LFE8-.LFB8
    .uleb128 0x4
    .long   0x0
    .byte   0x4
    .long   .LCFI6-.LFB8
    .byte   0xe
    .uleb128 0x8
    .byte   0x85
    .uleb128 0x2
    .byte   0x4
    .long   .LCFI7-.LCFI6
    .byte   0xd
    .uleb128 0x5
    .align 4
.LEFDE5:
    .ident  "GCC: (GNU) 4.1.2 (Ubuntu 4.1.2-0ubuntu4)"
    .section    .note.GNU-stack,"",@progbits

甚至更多的异常处理表和各种各样的额外信息。
所以，结论，至少对于Linux上的GCC：代价是额外的空间（用于处理程序和表），无论是否抛出异常，加上在抛出异常时解析表和执行处理程序的额外代价。2如果你使用异常而不是错误代码，并且很少出现错误，那么它可以 * 更快 *，因为你不再有测试错误的开销。
如果你想了解更多信息，特别是所有__cxa_函数的功能，请参阅它们的原始规范：

• Itanium C++ ABI

异常是缓慢的在过去是真实的。
在大多数现代编译器中，这不再适用。
注：我们有异常并不意味着我们不使用错误代码。当错误可以在本地处理时，请使用错误代码。当错误需要更多上下文才能更正时，请使用异常：我在这里写得更有说服力：指导您的异常处理策略的原则是什么？
当没有使用异常时，异常处理代码的开销实际上为零。
当抛出异常时，就完成了一些工作。
但是你必须把它和返回错误代码并一直检查到错误可以被处理的地方的成本进行比较，两者都需要更多的时间来编写和维护。
此外，对于新手来说，还有一个陷阱：
虽然Exception对象应该很小，但有些人在里面放了很多东西。然后你就有了复制Exception对象的成本。解决方法有两个：

• 不要在异常中添加额外的内容。
• 通过常量引用捕获。

在我看来，我敢打赌，相同的代码有异常是更有效的或至少是可比的代码没有异常（但有所有额外的代码来检查函数错误的结果）.记住，你不是免费得到任何东西编译器是生成代码，你应该写在第一位来检查错误代码（通常编译器是比人类更有效）.

有很多方法可以实现异常，但通常它们依赖于操作系统的一些底层支持。在Windows上，这是结构化异常处理机制。
关于代码项目的细节有体面的讨论：How a C++ compiler implements exception handling
异常开销的产生是因为编译器必须生成代码来跟踪当异常传播到作用域之外时，每个堆栈帧（或者更准确地说，作用域）中哪些对象必须被析构。如果一个函数在堆栈上没有需要调用析构函数的局部变量，那么它在异常处理方面不应该有性能损失。
使用返回代码一次只能展开堆栈的一个级别，而异常处理机制如果在中间堆栈帧中没有任何事情可做，则可以在一个操作中沿堆栈向下跳转得更远。

Matt Pietrek在Win32 Structured Exception Handling上写了一篇优秀的文章，虽然这篇文章最初写于1997年，但它仍然适用于今天（但当然只适用于Windows）。

This article研究了这个问题，基本上发现在实践中，异常是有运行时开销的，尽管如果不抛出异常，开销相当低。

几年前，我的一个朋友写了一些Visual C++如何处理异常的文章。
http://www.xyzw.de/c160.html

答案都很好。
另外，考虑一下在方法的顶部将“if检查”作为门来调试代码比允许代码抛出异常要容易得多。
我的座右铭是：写好代码很容易。最重要的是为下一个看到它的人写代码。在某些情况下，9个月后就是你了，你不想诅咒自己的名字吧！