要在抛出 ValueError 时立即中断，必须启用 VSCode 的「Raised Exceptions」断点并精确勾选 ValueError 类（而非仅 Exception）；断点命中后需在 Debug Console 中执行 traceback.print_exception(exc, chain=True) 才能查看完整异常链。
怎么在抛出 ValueError 时立即中断，而不是等它被吞掉
VSCode 默认不会在 ValueError 抛出瞬间停住——哪怕你写了 raise ValueError("bad input")，调试器也只会在“未捕获”时才响应（即没被 try/except 包住）。想让它一抛就断，必须启用「Raised Exceptions」断点，并精确勾选 ValueError 类本身。
操作路径：启动调试 → 左侧「运行和调试」面板 → 点击「断点」视图 → 展开「Python Exception Breakpoint」→ 勾选 ValueError（不是只勾 Exception）
- 勾
Exception通配类可能漏掉子类，比如ValueError在某些 debugpy 版本中不被父类断点触发 - 无需重启调试会话，勾选后实时生效；但若已运行中，需手动点「重新启动」才能加载新规则
- 如果项目用了
try/except捕获后又raise新异常（如raise RuntimeError()），原始ValueError的堆栈会丢失，断点自然失效
launch.json 里要不要加 "justMyCode": false
要，但仅当你要拦截第三方库抛出的特定异常。比如你依赖的 requests 内部抛了 ConnectionError，而你想立刻停在那里看上下文，就必须设 "justMyCode": false，否则调试器只在你自己写的代码里断，直接跳过 requests 的 raise 行。
不过副作用明显：
立即学习“Python免费学习笔记（深入）”；
- 断点可能频繁停进标准库或包源码（比如
urllib3、json），干扰主线逻辑排查 - 配合异常断点使用时，容易在你不关心的位置反复中断，建议仅在定位外部依赖异常时临时开启
- 不要把它当成“让异常链可见”的手段——它跟异常链显示完全无关，只是扩大了断点作用域
为什么断点设了却没停在 KeyError 上
常见原因不是配置错了，而是异常根本没“抛出来”。比如你写了：
try:
d["missing"]
except KeyError as e:
logger.error("key not found")
# 忘了 re-raise，也没 raise 新异常
这段代码里 KeyError 被静默吞掉了，调试器收不到任何信号，自然不会中断。这时候即使你勾了 KeyError 的「Raised」断点，也毫无反应。
- 检查是否所有
except块最后都有raise或raise e（注意：用raise Exception("xxx")会丢原始 traceback） - 协程中尤其危险：
async def函数里抛的异常，若没被await或asyncio.run()外层捕获，可能直接被事件循环丢弃，调试器根本收不到 - 某些框架（如 FastAPI）会全局捕获异常并转成 HTTP 500 响应，此时异常状态是「已捕获」，得勾「Raised」而非「Uncaught」才能中断
异常链（__cause__）在断点命中后怎么查看
断点停住后，VSCode 的「变量」面板里看不到 __cause__ 或 __context__ 字段，Debug Console 输入 exc 也只显示当前异常对象，链式结构默认隐藏。
真要看全链，必须手动调用：
import traceback traceback.print_exception(exc, chain=True)
其中 exc 是当前异常对象（可在「变量」面板里右键复制引用，或用 sys.exc_info()[1] 获取）。
- 别依赖
print_exc()或logger.exception()，它们默认chain=False，只输出最外层 - 如果异常来自
raise ... from ...语法，chain=True才能展开__cause__；如果是隐式链（比如except后再raise），则靠__context__，同样需要chain=True - 协程中异常链极易断裂，此时光靠调试器不够，得结合日志里的
tracecontextID 追踪跨await的错误源头
调试器对异常链的“视而不见”不是缺陷，而是设计取舍：它只响应当前 raise 动作，不递归解析关联异常。这意味着，想看清完整因果，得主动调用 traceback.print_exception(chain=True)，而不是指望界面自动展开。
