如何实现优雅的错误码检查，避免代码冗余与可读性下降？

方案1：统一错误处理分支（Goto 集中清理） #

把重复的错误检查、资源清理逻辑集中到固定标签处，状态机各分支仅负责业务逻辑与错误码判断，通过跳转复用清理逻辑。这是C语言环境下最实用的方案，既减少冗余又保持可读性。

示例代码：

err_code_t state_machine_run(state_t current_state) {
    err_code_t err = ERR_OK;
    BusHandle bus = NULL;
    MsgBuffer msg = {0};

    // 初始化资源
    bus = bus_open();
    if (ERR_OK != (err = bus_init(bus))) {
        goto cleanup_bus;
    }

    switch (current_state) {
        case STATE_SEND_DATA:
            err = bus_send(bus, &msg);
            if (ERR_OK != err) {
                goto cleanup_msg; // 跳转到对应层级的清理点
            }
            // 后续业务逻辑...
            break;
        case STATE_RECV_DATA:
            err = bus_recv(bus, &msg);
            if (ERR_OK != err) {
                goto cleanup_msg;
            }
            // 后续业务逻辑...
            break;
        // 其他状态分支...
    }

cleanup_msg:
    msg_buffer_free(&msg);
cleanup_bus:
    if (bus) bus_close(bus);
    return err;
}

• 优点：清理逻辑集中管理，状态分支只关注核心业务；新增状态时直接复用现有清理标签，无需重复编写代码。
• 注意：标签命名要清晰（如cleanup_xxx对应不同资源层级），避免无规则跳转导致逻辑混乱。

方案2：错误码链式封装（函数式调用） #

将错误检查逻辑封装为通用宏或内联函数，实现错误码的链式传递，同时自动触发清理动作，让业务代码更紧凑。

示例代码（C语言内联函数+宏）：

// 通用错误检查宏：错误发生时执行清理动作并返回
#define CHECK_ERR(err, cleanup_action) \
    do { \
        if (ERR_OK != (err)) { \
            cleanup_action; \
            return err; \
        } \
    } while(0)

// 总线发送安全封装：错误时自动执行清理
static inline err_code_t bus_send_safe(BusHandle bus, MsgBuffer* msg, void (*cleanup)(void)) {
    err_code_t err = bus_send(bus, msg);
    if (ERR_OK != err && cleanup) {
        cleanup();
    }
    return err;
}

err_code_t state_machine_run(state_t current_state) {
    err_code_t err = ERR_OK;
    BusHandle bus = bus_open();
    MsgBuffer msg = {0};

    CHECK_ERR(bus_init(bus), bus_close(bus));

    switch (current_state) {
        case STATE_SEND_DATA:
            err = bus_send_safe(bus, &msg, 
                                () { msg_buffer_free(&msg); bus_close(bus); });
            CHECK_ERR(err, ;); // 清理已在safe函数中执行，直接返回
            // 后续业务逻辑...
            break;
        case STATE_RECV_DATA:
            err = bus_recv(bus, &msg);
            CHECK_ERR(err, msg_buffer_free(&msg); bus_close(bus));
            // 后续业务逻辑...
            break;
    }

    // 正常流程清理
    msg_buffer_free(&msg);
    bus_close(bus);
    return ERR_OK;
}

• 优点：错误检查一行完成，无需重复编写判断与清理代码；封装的安全函数可跨场景复用。
• 注意：宏定义需用do-while(0)避免语法冲突；多线程环境下要确保清理动作线程安全。

方案3：RAII风格资源管理（C++环境） #

如果用C++开发，利用**资源获取即初始化（RAII）**机制，通过自定义资源类或智能指针自动管理资源生命周期，错误发生时自动调用析构函数清理，彻底消除手动清理代码。

示例代码：

// 总线资源管理类：自动释放总线
class BusGuard {
public:
    explicit BusGuard(BusHandle bus) : m_bus(bus) {}
    ~BusGuard() {
        if (m_bus) bus_close(m_bus);
    }
    // 禁用拷贝，避免资源重复释放
    BusGuard(const BusGuard&) = delete;
    BusGuard& operator=(const BusGuard&) = delete;
    // 提供总线访问接口
    BusHandle get() const { return m_bus; }
private:
    BusHandle m_bus;
};

// 消息缓冲区管理类：自动释放缓冲区
class MsgGuard {
public:
    MsgGuard(MsgBuffer* msg) : m_msg(msg) {}
    ~MsgGuard() {
        msg_buffer_free(m_msg);
    }
    MsgBuffer* get() const { return m_msg; }
private:
    MsgBuffer* m_msg;
};

err_code_t state_machine_run(state_t current_state) {
    err_code_t err = ERR_OK;
    BusHandle raw_bus = bus_open();
    BusGuard bus(raw_bus);
    MsgBuffer msg = {0};
    MsgGuard msg_guard(&msg);

    err = bus_init(bus.get());
    if (ERR_OK != err) {
        return err; // 析构函数自动清理bus和msg
    }

    switch (current_state) {
        case STATE_SEND_DATA:
            err = bus_send(bus.get(), msg_guard.get());
            if (ERR_OK != err) {
                return err; // 自动触发资源清理
            }
            // 后续业务逻辑...
            break;
        case STATE_RECV_DATA:
            err = bus_recv(bus.get(), msg_guard.get());
            if (ERR_OK != err) {
                return err;
            }
            // 后续业务逻辑...
            break;
    }

    return ERR_OK;
}

• 优点：完全消除手动清理代码，错误发生时自动释放资源；代码可读性极强，业务逻辑与错误处理完全分离。
• 注意：确保资源类析构函数能正确处理异常；复杂资源场景可结合移动语义优化性能。

方案对比与选择 #

• 纯C环境：优先选方案1（Goto集中清理），实现简单无依赖；方案2适合追求代码紧凑的场景，但要严格遵守宏使用规范。
• C环境：优先选方案3（RAII），这是C资源管理的最佳实践，从根源上避免冗余清理代码。
• 避坑提示：longjmp易破坏栈帧导致资源泄漏，调试难度大；板卡复位仅适合不可恢复的致命错误，不应作为常规错误处理手段。

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