当代码出错时，解释器在做什么
写代码的时候，谁还没见过几个红色的错误提示？比如你正忙着写一个视频转码脚本，结果运行时突然弹出 FileNotFoundError，程序直接卡住不动了。这时候你可能皱眉、叹气，但有没有想过，解释器在这个过程中到底经历了什么？
其实，每当代码出现异常，解释器并不会立刻“罢工”，而是启动一套内置的异常处理机制，试图搞清楚问题出在哪，然后决定是继续执行、跳转处理，还是干脆中止。
异常触发：错误是怎么被发现的
假设你正在用 Python 写一个音频文件分析工具，代码里写了这么一句：
with open("audio.mp3", "rb") as f:
data = f.read()
duration = len(data) / sample_rate # 假设 sample_rate 未定义运行时，解释器会逐行读取并执行。当它走到 sample_rate 这个变量时，发现这个名字根本没被绑定过，于是立刻抛出一个 NameError 异常。这个过程不是猜测，而是解释器在符号表里查不到对应条目后的标准反应。
异常传播：错误信息是如何“往上跑”的
异常不会原地消失。如果当前函数没有处理它，解释器就会把异常沿着调用栈一层层往上传。就像你在剪辑软件里点了“批量导出”，结果某个子任务出错了，主流程就得知道这件事，不能假装没发生。
比如上面的例子，如果这段代码在一个叫 analyze_audio() 的函数里，而这个函数又被 batch_process() 调用，那异常就会从 analyze_audio 一路冒泡回到 batch_process，直到有人“接住”它，或者整个程序崩溃。
捕获与响应：try-except 的实际作用
聪明的程序员不会让异常一路冲到终点。他们会提前设置“安全网”。最常见的就是 try-except 结构：
try:
duration = len(data) / sample_rate
except NameError:
print("采样率未定义，使用默认值 44100")
duration = len(data) / 44100这样，即使变量缺失，程序也能降级运行，而不是直接退出。对于媒体处理这类任务，这种容错能力特别重要——总不能因为一个文件出问题，整批剪辑都白干吧。
解释器的善后工作
如果异常没人处理，解释器也不会啥都不做。它会打印 traceback，也就是错误追踪信息，告诉你哪一行出了问题、调用路径是什么。这些信息不是为了吓唬人，而是帮开发者快速定位故障点。
同时，解释器会清理当前作用域的资源，比如关闭打开的文件句柄、释放内存。这就像家里漏水，关水阀的同时还得拖地，防止损失扩大。
自定义异常：让错误更“懂你”
有些场景下，内置异常不够用。比如你开发一个字幕同步工具，发现时间轴偏移太大，可以定义自己的异常类型：
class SyncOffsetError(Exception):
pass
if abs(offset) > 5.0:
raise SyncOffsetError(f"偏移超过5秒：{offset}秒")这样，其他部分的代码可以专门捕获 SyncOffsetError，做出重试或提醒操作，逻辑更清晰，维护也更容易。