C++异常调试：如何让std::source_location真正帮你定位问题

先说一个关键结论：std::source_location不会自动记录异常抛出位置，必须显式传入。它本质上与异常机制解耦，不参与栈展开过程。

为什么std::source_location不会自动出现在throw中

很多开发者容易产生一个误解：既然C++20引入了std::source_location，那么抛出异常时，编译器应该能自动捕获位置信息。但实际情况并非如此。

标准C++的throw语句本身并不隐式捕获源码位置。即便你写下throw std::runtime_error("msg")这样的代码，编译器也不会悄悄把当前文件名、行号塞进异常对象里。原因在于，std::source_location::current()只是一个普通的静态函数调用，需要开发者手动编写、显式传递。

• 典型现象：在catch块里，你往往只能拿到异常的消息字符串，完全不知道这个异常究竟是从代码的哪一行抛出来的。
• 根本原因：异常对象的构造和throw语句的执行是两个分离的步骤。std::source_location既不是std::exception的成员，也无法被运行时环境自动注入。
• 兼容性考量：从C++20开始可用，但所有使用点都需要手动添加。这种设计的好处是，旧代码完全无需改动，零迁移成本；但相应的，也意味着零自动收益。

如何让异常携带位置信息（实用封装方案）

最务实的做法，是定义一套封装机制，避免在每次抛出异常时都重复手写std::source_location::current()。这里提供两种主流思路。

• 使用宏（简洁，但调试体验有折衷）：

  #define THROW_RUNTIME_ERROR(msg) \
      throw std::runtime_error(std::string(msg) + " [" + \
          __FILE__ + ":" + std::to_string(__LINE__) + "]")

  这种方式写起来非常简洁，但调试时，断点或堆栈跟踪可能会指向宏定义所在的行，而非实际业务代码中throw的那一行。
• 使用C++20函数（类型安全，定位精准）：

  [[noreturn]] void throw_with_location(const char* msg,
      const std::source_location loc = std::source_location::current()) {
      throw std::runtime_error(
          std::string(msg) + " [" + loc.file_name() + ":" +
          std::to_string(loc.line()) + "]");
  }

  然后在业务代码中直接调用throw_with_location("invalid index")即可。这种方式支持断点精准定位到调用处，类型也更安全。
• 一个关键提醒：切忌在catch块内部调用std::source_location::current()来试图获取抛出位置——那记录的是catch语句自身的位置，完全不是当初throw的位置。

自定义异常类如何集成std::source_location

如果你的项目已经使用了继承自std::exception的自定义异常类型，集成位置信息同样直接。核心思路是在构造函数中接收并存储std::source_location，然后将其拼接到what()方法的返回值中。

立即学习“C++免费学习笔记（深入）”；

• 存储特性：std::source_location是“平凡可复制”的，这意味着它可以被直接作为异常类的成员变量保存，无需担心复杂的生命周期问题。
• 示例实现：

  class MyException : public std::exception {
      std::string msg_;
  public:
      MyException(const char* m,
          const std::source_location loc = std::source_location::current())
          : msg_(std::string(m) + " [" + loc.file_name() + ":" +
                 std::to_string(loc.line()) + "]") {}
      const char* what() const noexcept override { return msg_.c_str(); }
  };

• 性能影响：微乎其微。整个过程仅涉及一次字符串拼接，没有额外的动态内存分配。如果使用std::string_view来替代const char*传递消息，甚至可以避免一次拷贝。
• 需要警惕的坑：首先，不要将loc存储为引用或指针。其次，避免在构造函数中调用loc.function_name()后直接存储其返回的指针——某些编译器对该指针的生命周期不做保证，可能导致悬垂引用。

话说回来，技术实现本身并不复杂。真正的挑战在于工程一致性：如何确保项目里每一个throw点都走同一套封装路径。用宏容易遗漏，用函数又可能被无意绕过。而一旦某个throw漏掉了封装，日志链条就会在这里断掉——这种不一致性，有时比完全没有位置信息更令人困惑和误导。