Python健壮代码设计原则_异常与边界处理策略【教程】_技术教程

健壮的Python代码依赖明确的异常设计与边界处理。应区分TypeError（类型不支持）和ValueError（值不合逻辑），入口校验优于异常捕获，自定义异常需继承清晰、带结构化上下文，资源清理用try/finally或with，且异常策略须严格遵循接口契约。

健壮的 Python 代码不是靠“尽量不报错”实现的，而是靠明确知道哪里会出错、谁该处理、怎么恢复或退出。异常和边界处理不是补丁，是设计的一部分。

明确区分 `ValueError` 和 `TypeError` 的使用场景

很多开发者把所有参数错误都抛 ValueError，结果调用方无法区分是类型错了还是值不合逻辑。比如传入字符串 "123" 给一个只接受正整数的函数：类型没错（能转成 int），但语义上可能非法（如要求必须是质数）；而传入列表 [1, 2, 3] 就是典型的 TypeError。

TypeError：用于操作对象不支持该类型——例如对字符串调用 .append()，或函数收到非预期类型参数（如期待 int 却收到 list）
ValueError：类型正确但值不在允许范围内——例如 int("abc")、math.sqrt(-1)（未启用复数）、或自定义函数中 age=-5
不要用 Exception 或裸 raise 替代具体异常，这会让上游无法针对性捕获

边界检查优先于异常捕获

在函数入口做防御性校验，比依赖下游 try/except 更高效、更可读。尤其对索引、长度、空值等常见边界，显式检查比让 IndexError 或 KeyError 冒泡上来更利于调试。

def get_user_by_index(users: list, idx: int) -> dict:
    if not isinstance(users, list):
        raise TypeError(f"expected list, got {type(users).__name__}")
    if not users:
        raise ValueError("users list is empty")
    if not isinstance(idx, int):
        raise TypeError(f"index must be int, got {type(idx).__name__}")
    if idx < 0 or idx >= len(users):
        raise IndexError(f"index {idx} out of range for list of length {len(users)}")
    return users[idx]

避免先 try: return users[idx] 再 except IndexError —— 这掩盖了 users 是 None 或非 list 的问题
对 dict.get(key, default) 这类安全访问，仅在默认行为合理时使用；若缺失 key 意味着数据异常，应主动 raise KeyError(key)
数值计算前检查除零、溢出倾向（如用 math.isfinite() 过滤 NaN/inf）

自定义异常要带上下文，且继承层级清晰

写 class ValidationError(Exception) 没问题，但别让它孤零零躺在模块顶层。按领域分组，让调用方能用一个 except 捕获一类问题，比如所有输入校验失败。

class ApiError(Exception):
    """Base for all API-related exceptions"""
    pass

class ValidationError(ApiError):
    """Input validation failed"""
    def __init__(self, field: str, value, reason: str):
        self.field = field
        self.value = value
        self.reason = reason
        super().__init__(f"Validation failed on '{field}={value!r}': {reason}")

class RateLimitExceeded(ApiError):
    """API rate limit exceeded"""
    pass

异常类名体现意图，不叫 MyError 或 BadInput
构造时传入结构化信息（字段名、原始值、原因），而不是拼接字符串——方便日志提取或前端展示
避免在异常消息里打印 traceback 或敏感数据（如密码、token）
不要在 __str__ 中做耗时操作（如格式化大对象）

资源清理必须用 `try/finally` 或上下文管理器，别信 `except` 能覆盖一切

异常可能发生在任何地方，包括 except 块内部。指望靠多层 except 捕获并清理，不如用 finally 或 with 保证执行。

文件、网络连接、数据库游标等，优先用 with：它确保 __exit__ 执行，无论是否异常、是否 return、甚至 sys.exit()
手动管理资源时，try/finally 比 try/except/finally 更稳妥——因为 finally 总执行，而 except 可能漏掉新异常类型
不要在 finally 里吞掉异常（如 except Exception: pass），除非你明确知道为什么且已记录