异常处理机制演进：从错误码到SEH

我刚开始写程序那会儿，用的还是C语言。那时候处理错误，全靠函数返回值和一个全局的errno。说实话，那日子真是苦不堪言。后来我转战C++，接触了异常机制，才觉得世界清静了许多。再到后来做Windows底层开发，遇上了结构化异常处理（SEH），才真正理解了什么叫“系统性”的错误管理。

你想想看，一个程序从出生到跑崩，到底经历了怎样的错误处理变革？今天咱们就捋一捋这个演进脉络。我个人习惯把这段历史分成三个阶段：原始石器时代、农业革命、工业时代。听着有点玄乎？其实一点都不。

一、原始石器时代：错误码

早期C语言的错误处理策略，说白了就是“一个萝卜一个坑”。每个函数都返回一个整数，0表示成功，负数或正数表示不同的错误类型。如果你忘了检查返回值，那恭喜你，程序可能在你完全不知情的情况下跑偏了。

我记得有一次在一个嵌入式项目中，一个同事调用了malloc却忘了检查返回值。内存申请失败后，程序继续往下跑，导致后续所有指针操作都写到了非法地址。最后现场查了两天才定位到问题。嗯，这就是错误码时代的典型痛点——检查全靠自觉，遗漏无人提醒。

特性	错误码方式
错误传递	依赖返回值，每层都要检查并回传
资源清理	if-else里手动释放，容易遗漏
用户观察	看不见错误路径，只能看到最终症状
扩展性	新错误类型需要增加宏或枚举，耦合高

你可能会问：那为什么当年大家都这么干？因为硬件资源有限，CPU就那么点算力，编译器也不支持更高级的机制。再说，早期的程序规模小，错误路径不多，勉强能应付。

二、农业革命：异常处理的出现

后来C++引入了异常机制，大家终于不用在每个函数里手动检查错误码了。try、catch、throw三个关键字，让错误与正常逻辑分离。我在项目中用过一段时间后，真心觉得这玩意真是个好东西。

异常的核心逻辑其实很简单：当某层发现无法处理的问题时，直接抛出，由上层统一捕获。代码看起来干净了，错误传播路径也清晰了。

// C++异常示例
void ReadFile() {
    std::ifstream file("data.bin");
    if (!file.is_open()) {
        throw std::runtime_error("无法打开文件");
    }
    // 正常读取操作...
}

int main() {
    try {
        ReadFile();
    } catch (const std::exception& e) {
        std::cerr << "异常捕获: " << e.what() << std::endl;
        // 统一处理
    }
    return 0;
}

但是，异常也有自己的毛病。比如性能开销——一旦抛出异常，运行时需要展开堆栈、析构局部对象、查找匹配的catch块，这些操作都不便宜。我在一个高频交易系统中见过，为了极致性能，明确禁止使用异常，全部回归错误码。说白了，没有银弹。

三、工业时代：结构化异常处理（SEH）

真正让我感觉“开挂”的，是Windows平台的结构化异常处理（SEH）。我第一次用SEH是在调试一个驱动级别的崩溃时。那种能抓取非法内存访问、除零错误、甚至栈溢出错误的体验，跟普通catch完全不是一个量级。

SEH与普通异常的最大区别在于：它由操作系统直接提供支持，而不是语言层面模拟。对于PAE这种需要跟底层硬件强交互的课程来说，SEH才是真正需要掌握的东西。

// SEH结构化异常处理示例（MSVC扩展）
__try {
    int* p = nullptr;
    *p = 42;  // 故意触发访问违例
} __except(EXCEPTION_EXECUTE_HANDLER) {
    printf("捕获到硬件异常！\n");
    // 这里可以记录上下文、清理资源、甚至尝试恢复
}

嗯，这里要注意：SEH的__except关键字后面可以跟一个过滤器表达式，它比C++异常的catch更灵活。我曾经在项目中写过这样的代码：

__try {
    // 危险操作
} __except(
    GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION ?
        EXCEPTION_EXECUTE_HANDLER :
        EXCEPTION_CONTINUE_SEARCH
) {
    printf("只处理访问违例，其他异常继续向上传播\n");
}

你看这个过滤器，可以在捕获之前决定要不要处理。这在多层次异常处理中非常有用。我个人建议，凡是搞系统底层开发的，都应该把SEH的过滤器机制记牢。

SEH的另外一大好处是嵌套支持。你可以在外层套一个__try/__except，在内层再套一个__try/__finally，分别处理异常和保证资源释放。

__try {
    __try {
        // 可能产生异常的代码
    } __finally {
        // 无论是否异常，此块都会执行
        printf("清理资源\n");
    }
} __except(EXCEPTION_EXECUTE_HANDLER) {
    printf("捕获异常\n");
}

四、演进脉络总结

我把这三个阶段的核心差异整理成一个表格，方便你对照理解：

阶段	错误码时代	异常时代	SEH时代
支持层级	语言层面	语言层面	操作系统层面
错误类型	仅软件逻辑错误	软件逻辑错误为主	硬件+软件异常全覆盖
性能开销	几乎为零	抛出时有较大开销	可配置，硬件级支持更快
嵌套处理	手动实现	语言自动展开	__finally和__except嵌套
跨平台性	高	中（依赖编译器）	低（Windows专属）

说到这里，你可能会问：那到底该用哪种？我的答案是——看场景。写上层业务逻辑，用C++异常够用；写底层驱动或系统库，必须懂SEH；如果是嵌入式裸机，那还是老老实实用错误码+断言。

为了帮你更直观地理解这个演进过程，我画了一张图。不用死记硬背，多看几次就清晰了：

回到主题：PAE异常结构判定与校正，其实本质就是要在异常发生后，通过某种结构化手段识别异常类别、定位异常源头、判定异常是不是真的。你有了SEH这层认知，后面的课程就好理解了。