python不用错误码而用异常体系，因错误码易被忽略，异常强制处理更符合“显式优于隐式”原则；应区分可恢复与不可恢复错误，优先自定义异常而非数字码，仅极少数场景（如c扩展、cli退出码）例外。
Python中没有“错误码”机制，只有异常（Exception）体系。所谓“错误码”是C语言等底层语言的惯用做法，而Python的设计哲学强调“用异常明确表达错误条件”，不鼓励返回整数错误码来表示失败。
Python为什么不用错误码
错误码需要调用方手动检查返回值，容易被忽略；而异常强制中断流程并要求处理（或向上抛出），更符合“显式优于隐式”的原则。例如：
- C风格（不推荐）：函数返回-1表示失败，但调用者可能直接忽略，导致后续逻辑出错；
- Python风格（标准做法）：函数遇到非法输入直接抛出ValueError，调用方必须try/except或让程序崩溃——这反而提高了可靠性。
异常处理的核心策略
不是所有异常都要捕获，关键在于区分“可恢复错误”和“应终止错误”：
- 对用户输入校验失败（如非数字字符串转int），捕获ValueError并提示重试；
- 文件打开失败（FileNotFoundError），若该文件为必需配置，通常不应静默吞掉，而应记录日志后退出或抛出更明确的业务异常；
- 网络请求超时（TimeoutError或requests.exceptions.Timeout），适合重试+退避，而非转换成0或-1这类无意义错误码。
自定义异常比“模拟错误码”更清晰
如果想表达多种业务失败场景，不要用不同数字代表不同含义（如return 404、500），而是定义具体异常类：
立即学习“Python免费学习笔记（深入）”；
class InsufficientBalanceError(Exception): pass class InvalidPaymentMethodError(Exception): pass
这样调用方能精准捕获：except InsufficientBalanceError:，语义明确，调试友好，IDE也能自动提示。
极少数需兼容错误码的场景
仅在以下情况可考虑返回整数状态（但仍建议封装在异常中）：
- 与C扩展交互，需遵守原有API约定；
- 编写CLI工具且明确要求Unix风格退出码（如sys.exit(1)），但这属于进程级反馈，不用于函数内部逻辑控制。
总之，Python的异常不是“替代错误码的方案”，而是其原生、首选且经过充分验证的错误处理范式。坚持用异常，代码更健壮、可读性更高、协作成本更低。
