应避免在类方法中使用 except: 或 except Exception:，因其会掩盖编程错误、中断异常传播、干扰资源清理、破坏接口契约，并导致调试困难和协作障碍。
直接捕获 except: 或 except Exception: 会吞掉本该暴露的编程错误，破坏调用链、掩盖 bug、干扰调试，且无法区分可恢复与不可恢复错误。
类方法中捕获所有异常会中断调用栈传播
类方法通常被其他代码调用，异常是向上通知问题的重要信号。一旦在方法内部用 except Exception: 捕获并“静默处理”（比如只打日志或返回 None），上层就收不到原始异常，无法做针对性响应。
- 比如
user.save()内部捕获了DatabaseError却只打印一句“保存失败”，调用方完全不知道是连接超时、主键冲突还是字段为空 -
raise被拦下后，try-except外的finally或上下文管理器（如with）可能错过清理时机 - 测试时断言异常类型（如
self.assertRaises(IntegrityError, user.save)）直接失效
类方法常承担资源管理职责，宽泛捕获干扰清理逻辑
类方法里经常涉及文件、数据库连接、锁、临时状态等——这些必须在出错时可靠释放。但 except Exception: 容易让人误以为“已经兜底”，反而忽略 finally 或 with 的必要性。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 写法错误示例：
def load_config(self): try: return json.load(open(self.path)) except Exception: return {}—— 文件句柄没关闭，open()后直接裸奔 - 正确做法应优先用
with管理资源，异常只针对业务逻辑部分捕获，例如json.JSONDecodeError或KeyError -
BaseException子类（如KeyboardInterrupt、SystemExit）也会被Exception捕获，导致 Ctrl+C 失效，这在 CLI 工具类中尤为危险
类的契约会被模糊化，影响接口可维护性
用户调用一个类方法，依赖的是它的行为契约：成功返回什么、失败抛什么异常。宽泛捕获让这个契约坍塌，变成“可能返回任意值，也可能静默失败”。后续重构、mock、类型检查（如 mypy）全部受阻。
立即学习“Python免费学习笔记（深入）”；
- 例如
def calculate_tax(self, amount: float) -> float:声明返回float，但内部except Exception:后返回0.0或None，静态检查工具无法报错，运行时才暴露 - 当方法实际只可能因
amount 抛 <code>ValueError，却捕获所有异常，等于放弃对输入校验的明确表达 - 多人协作时，别人无法从方法签名或文档推断出它“到底会出什么错”，只能靠猜或读源码
真正需要兜底的场景极少，比如框架层的请求入口（Flask 的 view 函数）、CLI 主函数。普通类方法不是异常防火墙——它是业务逻辑的封装，异常就是它对外的语言。别替调用方做决定，更别替解释器隐藏错误。
