GCC下以异常实现流程控制，如何生成优化后的目标代码？

你的核心问题是用异常做局部流程控制，虽然能保持代码简洁，但带来了不必要的异常处理代码膨胀，同时还要保留调试器的错误干预机会。下面是几个实用的替代方案：

方案1：用std::optional替代异常，结合断言触发调试断点 #

把转换lambda改成返回std::optional<T>，明确标记转换成功/失败，同时用assert在错误时触发调试器断点，完全避免异常处理逻辑：

#include <optional>
#include <cassert>

shiny f(legacy const &l)
{
    auto convert_i = [](int i) -> std::optional<int>
    {
        switch(i)
        {
            case 1:    return 5;
            case 2:    return 9;
            default:   return std::nullopt;
        }
    };

    if (auto opt_val = convert_i(l.i))
    {
        return shiny { .i = *opt_val };
    }
    else
    {
        // Debug模式下触发断点并输出错误信息；Release模式可通过NDEBUG宏移除
        assert(false && "convert_i received invalid input value");
        return shiny { .invalid = true };
    }
}

这种方式代码简洁度和原来用异常差不多，但不会生成任何异常处理相关的代码，同时assert能让调试器在错误时暂停，满足你的调试需求。

方案2：封装通用转换模板，批量处理重复逻辑 #

如果有大量类似的转换lambda，可封装一个通用的检查转换函数，把错误判断和调试触发逻辑抽离，避免重复代码：

#include <cassert>
#include <utility>

// 通用转换检查函数：接收返回pair(成功标志, 结果值)的转换函数
template<typename ConvertFunc, typename... Args>
auto checked_convert(ConvertFunc&& func, Args&&... args)
{
    auto [success, value] = func(std::forward<Args>(args)...);
    if (!success)
    {
        assert(false && "Conversion failed");
    }
    return std::make_pair(success, std::move(value));
}

shiny f(legacy const &l)
{
    // 转换lambda只需要返回(是否成功, 转换后的值)
    auto convert_i = [](int i) -> std::pair<bool, int>
    {
        switch(i)
        {
            case 1:    return {true, 5};
            case 2:    return {true, 9};
            default:   return {false, 0};
        }
    };

    auto [valid, i_val] = checked_convert(convert_i, l.i);
    if (valid)
    {
        return shiny { .i = i_val };
    }
    else
    {
        return shiny { .invalid = true };
    }
}

这个方案把重复的错误处理逻辑集中到checked_convert里，所有转换lambda只需要关注核心转换规则，代码不会因为去掉异常而变得冗长，同时彻底消除了异常处理的代码开销。

方案3：GCC特定扩展，直接触发调试断点 #

如果不想改动太多原有逻辑，可利用GCC的__debugbreak()内置函数在错误时直接触发调试器断点，同时去掉异常逻辑：

shiny f(legacy const &l)
{
    int i_val;
    bool valid = true;

    switch(l.i)
    {
        case 1: i_val = 5; break;
        case 2: i_val = 9; break;
        default:
            __debugbreak(); // GCC下直接触发调试器断点
            valid = false;
            break;
    }

    return valid ? shiny { .i = i_val } : shiny { .invalid = true };
}

这种方式最直接，不需要额外的容器类型，但如果转换逻辑复杂、lambda数量多，会导致重复的判断代码，适合简单场景。

关键说明 #

• GCC中异常处理会生成EH帧、unwind表等额外代码，尤其是在函数内包含多个抛异常的lambda时，代码膨胀会更明显。上述方案都能完全避免这些开销。
• assert在Release模式下可通过定义NDEBUG宏移除，不会影响性能；如果需要在Release模式也保留调试触发，可替换为__builtin_trap()（会导致程序崩溃，但调试器能捕获崩溃点）。
• 用std::optional或std::pair<bool, T>作为错误返回方式，是C++中替代异常做局部流程控制的常规做法，代码可读性和简洁度都能和异常方案持平。

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