异常适用于真正出错、不该被忽略的意外情况，如文件缺失、网络不可达、严重参数错误；返回值适用于失败常见且需主动处理的场景，如字典取键、用户输入解析、查询无结果。
当操作失败属于“意外情况”而非“常规分支”时，该用异常；反之，如果调用方需要频繁检查、预期失败很常见（比如解析用户输入），返回值更合适。
异常适合：真正出错、不该被忽略的场景
异常的核心作用是中断正常流程，强制调用方处理问题。它适用于那些程序本不该走到、一旦发生就说明逻辑或环境出了问题的情况。
- 文件打开失败（
FileNotFoundError）：代码明确依赖某个配置文件存在，缺了就无法继续，不是“可能没有”的可选资源 - 网络请求超时或连接拒绝（
TimeoutError、ConnectionRefusedError）：服务端不可达，不是业务常态，需要重试、告警或降级 - 类型或参数严重错误（
TypeError、ValueError）：传入了明显非法的参数，比如math.sqrt(-1)，这不是需要容忍的输入变体，而是调用方 bug
返回值适合：失败是设计内的一部分、需主动判断的场景
当某种“失败”在业务逻辑中是常见、可预期、且调用方必须做不同处理时，返回值（如 None、False、Optional[T] 或自定义结果类）更清晰、更轻量。
- 字典取键（
dict.get(key, default)）：键不存在太常见，用.get()返回默认值比每次try/except KeyError更自然 - 解析用户输入（如
int("abc")）：用户输错是常态，应捕获ValueError并提示重输，但封装成函数时，返回None或Result[int, str]类型更利于链式处理 - 查找数据（如数据库查询无结果）：空结果不等于错误，而是有效业务状态，返回空列表或
None比抛异常更符合语义
关键判断标准：看“谁该负责处理”和“失败是否罕见”
问两个问题：
立即学习“Python免费学习笔记（深入）”；
- 这个失败，是当前函数能合理解决的吗？如果不能（比如没权限读文件），就该抛异常，让上层决定是重试、换路径还是报错退出
- 这个失败，在正常运行中发生的频率高吗？高频失败（如 API 返回 404）建议用返回值或显式状态码；低频失败（如磁盘突然满）才用异常
- 调用方是否总要检查？如果 90% 的调用都需要
try/except，说明它其实不是“异常”，而是接口契约的一部分，该改用返回值
别为了“看起来高级”而滥用异常
用异常控制流程（比如用 StopIteration 实现迭代器）是 python 内部机制，但自己写业务逻辑时，避免用异常替代 if/else。
- ❌ 错误示范：
def is_even(n): try: 2 // n; return True except ZeroDivisionError: return False—— 这是在用异常做条件判断，语义混乱且慢 - ✅ 正确做法：
return n != 0 and n % 2 == 0 - 异常开销比返回值大得多，频繁抛/捕异常会显著拖慢性能