17370845950

异常适用于真正出错、不该被忽略的意外情况，如文件缺失、网络不可达、严重参数错误；返回值适用于失败常见且需主动处理的场景，如字典取键、用户输入解析、查询无结果。

当操作失败属于“意外情况”而非“常规分支”时，该用异常；反之，如果调用方需要频繁检查、预期失败很常见（比如解析用户输入），返回值更合适。

异常适合：真正出错、不该被忽略的场景

异常的核心作用是中断正常流程，强制调用方处理问题。它适用于那些程序本不该走到、一旦发生就说明逻辑或环境出了问题的情况。

• 文件打开失败（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 比抛异常更符合语义

关键判断标准：看“谁该负责处理”和“失败是否罕见”

问两个问题：

• 这个失败，是当前函数能合理解决的吗？如果不能（比如没权限读文件），就该抛异常，让上层决定是重试、换路径

  

  还是报错退出
• 这个失败，在正常运行中发生的频率高吗？高频失败（如 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
• 异常开销比返回值大得多，频繁抛/捕异常会显著拖慢性能