在C++程序里，错误处理的取舍直接影响代码的健壮性和可维护性。异常处理机制由try、catch和throw三个关键字协作完成，它允许函数在发现问题时不就地解决，而是把错误信息以对象形式向上传递，直到某个调用者具备处理能力。这种方式把正常逻辑与错误处理解耦，但也带来了栈展开、性能开销等新课题。
一、try catch的基本语法结构
try块用于包围那些可能抛出异常的代码。一旦块内执行了throw语句，或者调用的函数抛出了异常，控制流会立刻跳出try块，转去匹配对应的catch子句。catch后面跟的是异常类型声明，类似于函数参数，可以用值或引用接收。
下面是一段最基础的示例，演示了除零时如何抛出一个整型错误码并被捕获：
#include <iostream>
int divide(int a, int b) {
if (b == 0) {
throw -1; // 抛出整型异常
}
return a / b;
}
int main() {
try {
int result = divide(10, 0);
std::cout << "result=" << result << std::endl;
} catch (int err) {
std::cout << "catch int exception: " << err << std::endl;
}
return 0;
}
上述代码中，divide函数在除数为零时抛出-1，main中的try块捕获到该整型异常并打印信息。值得注意的是，catch使用的是值捕获，若异常对象较大，建议使用const引用以减少拷贝。
如果try块中没有抛出异常，程序会跳过所有catch直接执行后续代码。catch的匹配是从上到下进行的，因此更具体的异常类型应当写在前面，避免被泛化捕获吃掉。
二、抛出标准异常与自定义异常
C++标准库在<stdexcept>头文件中定义了一组异常类，如std::runtime_error、std::invalid_argument等，它们都继承自std::exception。使用标准异常可以让接口更符合通用约定，也方便上层统一处理。
当需要携带业务语义时，自定义异常类是更好的选择。自定义类通常公开继承std::exception，并重写what()方法返回描述信息。这样既能用基类引用捕获，又能保留细分类型。
#include <stdexcept>
#include <string>
class NetworkError : public std::runtime_error {
public:
explicit NetworkError(const std::string& msg)
: std::runtime_error(msg) {}
};
void connect() {
throw NetworkError("connection timeout");
}
int main() {
try {
connect();
} catch (const std::exception& e) {
// 用基类引用捕获，可处理所有标准及自定义异常
std::cout << "error: " << e.what() << std::endl;
}
return 0;
}
通过继承体系，调用方只需捕获std::exception引用即可覆盖大多数错误，同时派生类信息不会丢失。相比单纯throw字符串或错误码，这种做法类型安全且易于扩展。
需要提醒的是，不要在析构函数中抛出异常，因为若恰逢栈展开阶段，会导致程序直接调用std::terminate终止。资源清理逻辑应当吞掉内部错误或用普通标志记录。
三、栈展开与资源管理
当异常抛出后，从throw点到catch点之间所有已构造的局部对象会按相反顺序析构，这一过程称为栈展开。它保证了对象生命周期的正确性，但也隐含了资源泄漏风险，例如裸指针申请的内存若未释放就抛出异常，便会丢失。
解决该问题的现代做法是使用RAII（资源获取即初始化），把资源绑定到对象生命周期上。例如用std::unique_ptr管理动态内存，无论正常返回还是异常跳出，指针析构都会自动释放。
#include <memory>
#include <iostream>
void process() {
std::unique_ptr<int> p(new int(42));
throw std::runtime_error("fail after alloc");
// 若没有异常，p在函数结束时释放
// 若抛异常，栈展开时p析构，内存依旧释放
}
int main() {
try {
process();
} catch (const std::exception& e) {
std::cout << "caught: " << e.what() << std::endl;
}
return 0;
}
RAII让异常安全变得自然，不必在每个catch里手写释放逻辑。这也是为什么现代C++强调用智能指针、容器和标准锁代替裸资源操作。
如果必须在异常路径上做特定清理，可以使用catch捕获后重新抛出，即写catch(...) { 清理; throw; }，但更推荐把清理放进析构函数或借助scope_exit式工具。
四、catch的匹配规则与多重捕获
catch子句按顺序匹配，且只匹配类型，不关心值。派生类异常可以被基类引用捕获，因此基类捕获应放在派生类之后，否则永远走不到细分处理。也可以用catch(...)捕获一切，通常作为最后兜底。
多重捕获常用于同一段逻辑可能抛出不同标准异常的场景，例如文件读取既可能无效参数也可能读写失败。下面展示如何分别处理：
#include <iostream>
#include <stdexcept>
void readConfig(bool bad) {
if (bad) {
throw std::invalid_argument("bad config");
}
throw std::runtime_error("io error");
}
int main() {
try {
readConfig(true);
} catch (const std::invalid_argument& e) {
std::cout << "config error: " << e.what() << std::endl;
} catch (const std::runtime_error& e) {
std::cout << "runtime error: " << e.what() << std::endl;
} catch (...) {
std::cout << "unknown error" << std::endl;
}
return 0;
}
这个结构清晰地分离了配置错误与运行错误，便于分别上报或重试。catch(...)虽然能兜住所有异常，但拿不到类型信息，一般只用于记录日志后重新抛出或终止程序。
在真实项目中，顶层main函数常写一层catch(const std::exception&)和catch(...)，防止未处理异常导致进程直接崩溃，同时输出诊断信息辅助排查。
五、异常使用的常见误区
第一个误区是把异常当作普通控制流，例如用抛出来结束循环。这会带来可观的性能损耗，且让代码难以阅读。异常应只用于真正意外的情况。
第二个误区是在性能极度敏感的内层循环频繁抛catch，C++异常在抛出路径上成本较高，虽然不抛时几乎免费，但高频异常会拖慢系统。此时返回错误码更合适。
// 不推荐：用异常做正常流程控制
int findIndex(int val) {
throw val; // 错误示范
}
// 推荐：用返回值或optional表达可能失败
#include <optional>
std::optional<int> findIndexSafe(int val) {
if (val < 0) return std::nullopt;
return val;
}
第三个误区是忽略异常说明的演变。旧标准中的throw()动态异常规范已被C++11弃用，改用noexcept指明不抛异常，这既是对编译器的优化提示，也是对接口的契约声明。
掌握这些边界，才能让try catch成为可靠的防护网，而不是隐藏bug的迷雾。写新代码时，优先用标准异常加RAII，既规范又省心。