异常处理

函数异常块

函数异常块是函数体的一种替代语法，主要用于应对初始化列表抛出的异常，在析构函数或其他常规函数中极少使用：

struct S {
   std::string m;
   S(const std::string& arg) try : m(arg, 100) {
      std::cout << "constructed, mn = " << m << '\n';
   } catch(const std::exception& e) {
      std::cerr << "arg=" << arg << " failed: " << e.what() << '\n';
   } // 此处隐式 throw;
};

异常规范

C++使用跟在函数名后面的 throw 说明函数会抛出的异常。（ C++11已废用 ）

例：

void func1() throw(std::bad_exception, std::bad_alloc);

该异常规范已经在C++11被弃用，但是仍然可能存在于某些代码中。

C++ 还引入了一个新的关键字： noexpect

noexpect 有两种用法：

  • 用于保证函数不会抛出异常。

    void func1() noexcept;

    若一个函数被 noexcept 修饰，但是仍然抛出了异常，则编译器会出现警告。

  • 用来判断函数是否被 noexcept 修饰：

    noexcept(func1) == true

    noexcept 表达式的返回值是一个右值 bool 类型。

  • noexcept 可以用来帮助编译器优化代码

  • noexcept 与 throw() 相同，尽管都为函数声明的一部分，但是不允许出现在 typedef 中

  • 函数违反了 noexcept 并不会导致调用 unexpected() ，也不会出现 栈解退

构造函数和析构函数中的异常

  • 构造函数可以抛出异常。抛出异常后不会调用析构函数。内存会被回收，但是系统资源不会被回收

  • 析构函数默认是 noexcept。但是依然可以抛出异常

栈解退

测试代码如下：

#include <iostream>
#include <exception>

void func1();
void func2();
using namespace std;

int main() {
   try {
      try {
            func1();
            cout<<"第二层try块"<<endl;
      } catch (exception&e) {
            cout<<"第二层catch"<<endl;
      }
      cout<<"第一层try块"<<endl;
   } catch (std::exception&e) {
      cout<<"第一层catch"<<endl;
   }
   return 0;
}

void func1(){
   func2();
   cout<<"func1()"<<endl;
}
void func2(){
   throw std::bad_exception();
}

运行结果如下:

第二层catch

第一层try块

也就是说：当 func2 引发异常后，函数直接跳转到了 第二层try块 的结尾，然后直接进入 第二层catch 块。而若是函数返回的话，则会先返回到 func1() 然后再执行 第二层try块 的剩余语句。

异常处理中以下行为被保证：[1]

  • 栈解退时函数调用栈的所有栈对象将被析构，而堆对象不会

  • 若类的析构函数抛出异常，则直接调用 std::terminate() 中断程序

  • 若类的构造函数抛出异常，则撤销所有已构造成员

  • catch中允许 非const到const、派生类到基类、数组和函数到指针 之间的类型转换（前提是使用引用）

  • 异常类型匹配将优先选择第一个可以处理该异常的catch子句

  • throw抛出的异常对象对象将被保留至异常被处理为止

  • catch子句获得的只是异常对象的副本（使用引用类型只是为了多态）

  • 异常对象必须是可复制的

  • 抛出一个表达式时，被抛出对象的静态编译时类型将决定异常对象的类型

  • 若被catch的是基类指针，则派生类将被切片。

  • catch可以 throw; 将捕获的异常重新抛出，否则视为已处理

异常中断

异常在两种情况下会引发中断：

  • 若函数引发的异常未被捕获（即 未捕获异常 (uncaught exception) ），则调用 std::terminate() 中断程序。

  • 若函数引发了不在异常规范列表中的异常（即 意外异常 (unexpected exception) ），则调用 std::unexpected 中断程序。

默认情况下 std::terminate() 将会调用 std::abort() 中断程序，通过 set_terminate() 可以自定义 std::terminate() 调用的函数。例如：

#include <iostream>
#include <exception>

using namespace std;

void myQuit(){
   cout<<"myQuit()"<<endl;
}

int main() {
   set_terminate(myQuit);
   throw bad_exception();
   return 0;
}

输出结果为:

myQuit()

进程已结束，退出代码 134 (interrupted by signal 6: SIGABRT)

std::terminate() 被 noexception 修饰，若 std::ter11 .

上篇文章说过，在异常抛出栈展开的时候，编译器会适当撤销函数退出前分配的局部空间，如果局部对象是类类型，则自动调用它的析构函数。但如果在函数内单独地使用new动态的分配了内存，而且在释放资源之前发生了异常，那么栈展开时这个动态空间将不会被释放。而由类类型对象分配的资源不管是静态的还是动态的一般都会适当的被释放，因为栈展开时保证调用它们的析构函数。因此，在可能存在异常的程序以及分配资源的程序最好使用类来管理那些资源，看一个例子：nate() 抛出异常，则会通过 std::abort 终止程序，但是不会再有 异常中断提示

默认情况下 std::unexpected 将会调用 std::terminate() 中断程序，可以通过 set_unexpected 自定义 std::unexpected 调用的函数。例如：

#include <iostream>
#include <exception>

using namespace std;

void myQuit(){
   cout<<"myQuit()"<<endl;
}

void myUnexcepted(){
   cout<<__FUNCTION__ <<endl;
}

int main() throw(bad_alloc) {
   set_terminate(myQuit);
   set_unexpected(myUnexcepted);
   throw bad_exception();
   return 0;
}

输出结果为:

myUnexcepted
myQuit()

进程已结束，退出代码 134 (interrupted by signal 6: SIGABRT)

需要注意的是：若 std::unexpected 中抛出了异常，则：

  • 若新抛出的异常与原来的异常规范匹配，则从抛出异常的位置继续处理异常

  • 若新抛出的异常与原来的异常规范不匹配，且异常规范中没有 std::bad_exception ，则调用 std::terminate 终止程序。

  • 若新抛出的异常与原来的异常规范不匹配，且异常规范中包含了 std::bad_exception ，则将新抛出的异常替换为 std::bad_exception

零成本异常并不是零成本

译自： Zero-cost exceptions aren’t actually zero cost

C++ 中有两种常见的异常处理模型。一种是在异常方式时通过做一系列工作来更新程序状态。例如，进入异常处理作用域或者退出作用域。另一种模型是使用元数据来描述发生异常是应该做什么，运行时没有对状态的显式管理。相反，异常机制通过查看程序计数器和查询元数据来推断状态

基于元数据的异常处理通常被 误导性地称为零成本异常 ，这听起来像是异常没有成本。事实上完全相反，基于元素的异常应当被称为 超级昂贵的异常

基于元数据的异常处理的要点是：在主线（非异常）代码路径中没有用于异常支持的代码，异常发生的次数很少，因此您最终会得到更好的性能。

模式运行时管理基于元数据

主线代码

在运行时更新状态

发生异常

查询状态以找到正确的处理程序

获取程序计数器并找到适用它的元数据，查询元数据以找到正确的处理程序

请注意：使用基于元数据的所谓”零成本“异常实际上会导致抛出异常的成本显著增加，因为抛出异常的机器必须找到元数据以便查找要运行的处理程序。此元数据通常以 针对大小而非速度的格式 储存，因此必须在抛出异常时进行额外的工作以解码数据来找到正确的处理程序

“零成本异常”的名字意指没有生成额外的代码来防止异常发生

但即使是这样，也并不是零成本异常就和没有异常一样

异常的存在意味着代码生成受制于隐式约束：在执行任何可能引发异常的操作之前，如果对象对于一个异常处理是可见的，那么编译器必须将对象状态储存到内存中。（任何带有遇析构函数的对象都是可见的，因为异常处理程序可能必须运行析构函数）

简单来讲，潜在的可抛出异常操作限制了编译器优化可观察对象的能力，因为异常流和主线代码是相互独立的

这些成本是肉眼不可见的。他们会导致失去优化的机会

零成本例外很好（尽管用词不当），但请注意，成本实际上并不为零。 号

Last moify: 2023-12-20 04:16:56
Build time：2025-07-18 09:41:42
Powered By asphinx