📚 课程目录第4章异常处理与调试

4. 异常处理与调试：try-except、日志记录、断点调试，提升脚本的健壮性与可维护性

在Python自动化测试与仪器控制领域，脚本往往需要长时间运行、与多种硬件设备交互、处理海量测量数据。一个没有异常处理与调试机制的脚本，如同在雷区中裸奔——一旦设备未连接、返回异常数据或网络超时，整个测试流程可能瞬间崩溃，且难以定位问题根源。本章将系统讲解如何通过try-except异常捕获、结构化日志记录与断点调试三大核心手段，构建具备高健壮性与可维护性的自动化脚本。我们将从异常处理的核心原理出发，深入日志记录的工程实践，再结合断点调试的实战技巧，最终通过一个完整的仪器控制案例，展示三者的协同应用。

上图展示了本章的核心知识框架：异常处理、日志记录与断点调试三者相互支撑，共同服务于脚本的健壮性与可维护性目标。异常处理负责“接住”错误，日志记录负责“记录”错误，断点调试负责“定位”错误。在实际工程中，三者缺一不可，且需要协同设计。下面我们将逐一深入剖析。

4.1 异常处理：构建脚本的“安全气囊”

4.1.1 核心原理：异常传播与捕获机制

Python的异常处理基于异常对象的传播机制。当代码执行出错时，解释器会创建一个异常对象，并沿调用栈向上抛出。若在当前位置未捕获，异常会逐层向上传递，直到被某个try-except块捕获，或最终导致程序终止。理解这一机制是编写健壮脚本的基础。

在仪器控制场景中，常见的异常类型包括：VisaIOError（设备通信失败）、TimeoutError（读取超时）、ConnectionError（网络断开）、ValueError（参数越界）以及FileNotFoundError（配置文件缺失）。合理的异常处理策略应针对不同异常类型采取不同恢复动作，而非笼统地捕获所有异常。

核心原则：异常处理不是“吞掉错误”，而是“分类处理、记录现场、优雅降级”。捕获异常后至少应记录日志，并决定是重试、跳过、使用默认值还是终止程序。

4.1.2 操作流程：try-except-else-finally的完整用法

一个完整的异常处理块包含四个子句，每个都有其独特用途：

try:
    # 可能出错的代码
    value = instrument.query(":MEAS:VOLT:DC?")
    voltage = float(value)
except VisaIOError as e:
    # 处理特定异常：设备通信失败
    log.error(f"设备通信失败: {e}")
    raise  # 或执行重试逻辑
except (ValueError, TypeError) as e:
    # 处理多个异常：数据解析错误
    log.warning(f"数据解析异常，原始值: {value!r}, 错误: {e}")
    voltage = 0.0  # 使用默认值
except Exception as e:
    # 兜底异常：未知错误
    log.critical(f"未预期的错误: {e}", exc_info=True)
    raise SystemExit(1)
else:
    # 无异常时执行（可选）
    log.debug(f"成功读取电压: {voltage} V")
finally:
    # 无论是否异常都执行（资源清理）
    instrument.close()
    log.info("仪器连接已释放")

关键要点：else子句确保只有try块完全成功时才执行后续逻辑，避免在异常情况下误操作；finally子句用于释放资源（关闭连接、删除临时文件），保证即使发生异常也不会泄漏资源。

4.1.3 案例拆解：多设备测试台的异常恢复策略

假设我们管理一个包含5台示波器、3台信号发生器的自动化测试台，每台设备通过GPIB或LAN连接。测试脚本需要依次完成100个测试点的数据采集。初始现象：某台示波器偶尔因缓存溢出返回错误数据，导致整个测试流程中断。

我们设计如下异常处理策略：

异常类型	处理策略	重试次数	降级方案
VisaIOError (通信超时)	重试3次，间隔2秒	3	跳过该测试点，记录警告
ValueError (数据格式错误)	重新读取一次	1	使用上一次有效值
ConnectionError (设备掉线)	重新初始化设备	2	标记设备离线，继续其他设备
KeyboardInterrupt	立即停止，保存已测数据	-	生成部分报告

实施后，测试完成率从78%提升至99.2%，平均单次测试时间减少15%（因不再频繁中断重启）。关键经验：重试必须设置上限和间隔，否则可能陷入死循环；降级方案必须保证数据可追溯，不能静默使用错误值。

常见误区：过度使用except Exception会掩盖编程错误（如拼写错误、逻辑错误）。建议至少区分预期异常（通过except捕获）和非预期异常（让程序崩溃以便发现bug）。另外，不要在except块中写空的pass，这会让错误完全不可见。

4.2 日志记录：让脚本“开口说话”

4.2.1 核心原理：日志级别与传播链

Python的logging模块采用Logger-Handler-Formatter三级架构。Logger负责产生日志消息，Handler决定输出到哪里（文件、控制台、网络），Formatter定义输出格式。日志级别从低到高为：DEBUG、INFO、WARNING、ERROR、CRITICAL。合理设置级别可以控制日志的详细程度，避免生产环境被海量调试信息淹没。

在自动化测试中，日志不仅是排障工具，更是审计证据。当测试结果出现争议时，完整的日志可以还原整个操作过程。因此，日志应记录：操作时间、操作内容、输入参数、输出结果、耗时、异常信息（含堆栈）。

4.2.2 操作流程：配置双通道日志系统

一个实用的日志配置应同时输出到控制台（实时监控）和文件（持久化），并支持轮转防止磁盘占满：

import logging
from logging.handlers import RotatingFileHandler

def setup_logger(name="autotest", log_file="test_run.log"):
    logger = logging.getLogger(name)
    logger.setLevel(logging.DEBUG)
    
    # 控制台Handler：显示INFO及以上
    console = logging.StreamHandler()
    console.setLevel(logging.INFO)
    console_fmt = logging.Formatter('%(asctime)s - %(levelname)s - %(message)s')
    console.setFormatter(console_fmt)
    
    # 文件Handler：记录DEBUG及以上，轮转5MB*3个备份
    file_handler = RotatingFileHandler(log_file, maxBytes=5*1024*1024, backupCount=3, encoding='utf-8')
    file_handler.setLevel(logging.DEBUG)
    file_fmt = logging.Formatter('%(asctime)s | %(name)s | %(levelname)s | %(module)s:%(lineno)d | %(message)s')
    file_handler.setFormatter(file_fmt)
    
    logger.addHandler(console)
    logger.addHandler(file_handler)
    return logger

log = setup_logger()

使用logger.exception()在except块中记录异常时，会自动附加堆栈信息，这是定位问题的关键。同时，建议在关键操作（如设备初始化、测试点切换）前后添加INFO级别日志，形成操作轨迹。

4.2.3 实战场景：仪器控制脚本的日志规范

以下是一个典型的仪器控制日志片段，展示了结构化记录的价值：

2025-01-15 14:23:01,456 | autotest | INFO | main.py:42 | 初始化信号发生器: GPIB0::10::INSTR
2025-01-15 14:23:02,102 | autotest | DEBUG | main.py:55 | 设置频率: 1.000000e+09 Hz, 功率: -10.0 dBm
2025-01-15 14:23:02,890 | autotest | INFO | main.py:78 | 测试点 #12 开始: 频率扫描
2025-01-15 14:23:05,234 | autotest | WARNING | main.py:91 | 示波器CH2读数异常: 0.000 V, 重试第1次
2025-01-15 14:23:07,456 | autotest | ERROR | main.py:95 | 示波器CH2读数超时, 已跳过该点
Traceback (most recent call last):
  File "main.py", line 88, in read_scope
    raw = scope.query(":MEAS:VPP? CH2")
  File "visa.py", line 456, in query
    raise VisaIOError("Timeout")
2025-01-15 14:23:08,001 | autotest | INFO | main.py:120 | 测试点 #12 完成, 耗时: 5.1s, 结果: SKIP

这样的日志让运维人员无需查看代码即可理解发生了什么。注意敏感信息脱敏：如果日志中包含设备IP、密码等，应使用过滤器替换。

经验提醒：日志不是越多越好。DEBUG级别用于开发调试，生产环境建议设为INFO。同时，避免在循环内打印大量DEBUG日志，可使用logger.isEnabledFor(logging.DEBUG)进行性能优化。

4.3 断点调试：精准定位问题的“手术刀”

4.3.1 核心原理：断点类型与调试会话

断点调试允许程序在指定行暂停，开发者可以检查变量值、调用栈、执行流程。现代IDE（如VS Code、PyCharm）提供了丰富的断点类型：普通断点（每次执行到该行暂停）、条件断点（满足条件才暂停）、日志断点（不暂停但输出信息）、异常断点（抛出异常时自动暂停）。

在仪器控制中，断点调试尤其适用于：排查通信协议问题（检查发送的命令是否正确）、验证数据解析逻辑（查看原始返回字节）、分析时序问题（确认设备响应时间）。

4.3.2 操作流程：从pdb到IDE的调试实践

当无法使用IDE时，pdb模块是命令行下的利器。在代码中插入breakpoint()即可启动调试器。常用命令：

import pdb; pdb.set_trace()  # 传统方式
breakpoint()  # Python 3.7+ 推荐

# pdb常用命令
# n (next)      : 执行下一行
# s (step)      : 进入函数内部
# c (continue)  : 继续执行到下一个断点
# p 变量名      : 打印变量值
# l (list)      : 查看当前代码上下文
# w (where)     : 打印调用栈
# q (quit)      : 退出调试器

在VS Code中，可以设置条件断点，例如当voltage < 0时暂停，这对于排查偶发异常非常有效。同时，利用监视窗口持续观察关键变量的变化趋势。

4.3.3 案例拆解：调试一个“幽灵”数据错误

背景：某温度采集系统，使用Python脚本通过串口读取温控器数据。脚本运行数小时后，偶尔出现温度值跳变（如从25.3°C跳变到-45.7°C），但无法稳定复现。

调试过程：

初步排查：在读取数据行设置普通断点，观察原始串口数据。发现跳变时，串口返回的字节流中混入了异常字符（如b'25.3\x00\xff'）。
条件断点：设置条件断点if b'\xff' in raw_data，捕获到异常数据出现的时机。发现异常总在温控器发送“报警状态”帧时发生。
调用栈分析：查看调用栈，发现数据解析函数parse_temp()未处理帧边界，将两帧数据拼接后解析。
修复：在解析前增加帧同步校验，丢弃不完整帧。

结果：修复后连续运行72小时无异常。复盘经验：断点调试的价值在于“看到”数据流，而非猜测。对于偶发问题，条件断点比普通断点更高效。

风险提示：在硬件通信循环中设置断点可能导致设备超时（因为程序暂停时设备仍在等待响应）。调试时建议使用日志断点（不暂停）或增加超时时间。另外，调试完成后务必移除所有breakpoint()，避免生产环境意外暂停。

4.4 三者的协同：构建完整的错误处理闭环

4.4.1 协同模式：异常-日志-调试的联动

一个成熟的自动化脚本应形成如下闭环：异常触发 → 日志记录现场 → 决策恢复策略 → 必要时进入调试模式。例如，可以在环境变量中设置DEBUG_MODE=1，当脚本捕获到未预期异常时，自动打开pdb调试器：

import os
import sys

def handle_unexpected_exception(exc_type, exc_value, exc_tb):
    log.critical("未捕获异常", exc_info=(exc_type, exc_value, exc_tb))
    if os.getenv("DEBUG_MODE") == "1":
        import pdb
        pdb.post_mortem(exc_tb)  # 进入异常现场调试
    else:
        sys.exit(1)

sys.excepthook = handle_unexpected_exception

这种设计让开发环境可以深入调试，而生产环境则安全退出并记录完整日志。

4.4.2 知识结构总结

维度	异常处理	日志记录	断点调试
核心目标	防止崩溃，优雅降级	记录证据，追溯问题	定位根因，修复缺陷
使用时机	代码运行期	全程	开发/排障期
输出物	控制流跳转	日志文件/控制台	交互式调试会话
性能影响	低（仅异常时）	中（I/O操作）	高（暂停执行）
生产环境	必须启用	必须启用	通常禁用

4.4.3 总结复盘：常见误区与最佳实践

通过本章学习，我们应避免以下常见误区：

误区一：捕获所有异常但不处理，导致错误被静默忽略。应至少记录日志。
误区二：日志信息过于简略，缺少上下文（如设备地址、操作参数）。应包含关键变量值。
误区三：调试时修改代码后忘记移除断点，导致生产环境意外暂停。应使用版本控制检查。
误区四：在性能敏感的循环中过度使用日志，拖慢测试速度。应合理设置日志级别。

最佳实践总结：首先，为脚本定义清晰的异常层次结构，区分可恢复与不可恢复错误；其次，建立统一的日志配置模块，确保所有模块使用同一套日志体系；最后，将调试工具（如pdb、IDE配置）纳入项目文档，方便团队协作。记住，健壮性不是“不犯错”，而是“犯错后能快速恢复并留下线索”。