健壮的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 捕获一类问题，比如所有输入校验失败。
立即学习“Python免费学习笔记（深入）”；
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），除非你明确知道为什么且已记录
最常被忽略的一点：边界和异常策略必须随接口契约演进。当函数文档说“返回非空列表”，那空列表就是 bug 或异常信号，不是正常分支；当类型注解写 str，运行时就该拒绝 bytes——哪怕它能 decode。健壮性藏在契约的严格执行里，不在层层套娃的容错中。
