封装第三方库异常是为了统一错误语义、隐藏技术栈、控制传播范围，需保留原始异常上下文、透传关键属性、分层分类而非过度兜底。
为什么要封装第三方库异常
直接暴露 requests.exceptions.ConnectionError 或 psycopg2.OperationalError 会让调用方被迫感知底层实现细节。一旦你换掉 HTTP 客户端或数据库驱动，上层逻辑就得跟着改异常处理逻辑。封装的核心目的不是“换个名字”，而是统一错误语义、隐藏技术栈、控制错误传播范围。
封装时别只做简单继承——得保留原始异常的上下文（traceback、message、cause），否则调试时会丢失关键信息。
用 raise ... from 保留原始异常链
Python 3 的异常链机制是封装的标配。它既让自定义异常成为主错误，又不丢掉原始异常的完整堆栈。
常见错误是写成：
raise MyNetworkError("请求失败") # ❌ 丢掉了 requests 异常的 traceback 和 status_code正确做法是：
try:
response = requests.get(url)
response.raise_for_status()
except requests.exceptions.RequestException as e:
raise MyNetworkError(f"HTTP 请求异常：{e}") from e # ✅ 保留原始异常这样调用方看到的是 MyNetworkError，但用 traceback.print_exc() 能同时看到两层异常，且 e.__cause__ 可访问原始 requests 异常实例。
立即学习“Python免费学习笔记（深入）”；
在自定义异常类中透传关键属性
很多第三方异常带实用属性，比如 requests.Response 对象、psycopg2.Error.pgcode、redis.ConnectionError.args[0]。如果封装时不提取并挂载到自定义异常上，上层就无法做精细化判断。
建议在自定义异常构造器中显式提取并存储：
- 检查原始异常是否有
.response、.pgcode、.args等字段 - 用
setattr(self, 'response', e.response)或self.pgcode = getattr(e, 'pgcode', None)挂载 - 避免在
__str__里拼接敏感信息（如完整 SQL、token），生产环境要过滤
示例：
class MyDatabaseError(Exception):
def __init__(self, message, original_exc):
super().__init__(message)
self.pgcode = getattr(original_exc, 'pgcode', None)
self.diag = getattr(original_exc, 'diag', None)避免过度封装导致调试困难
有些团队会把所有第三方异常都兜底转成一个 AppError，再靠错误码区分——这反而增加了定位成本。更务实的做法是按领域分层封装：
比如网络层用 MyNetworkError，数据库层用 MyDatabaseError，文件系统用 MyFileIOError。每类异常对应一组可预期的恢复策略（重试？降级？告警？），而不是靠字符串匹配错误信息。
另外，别在封装时吞掉异常——除非你明确知道该忽略（比如某些幂等接口的 404）。静默吞掉 ConnectionRefusedError 或 PermissionError 会让问题延迟暴露，排查时只能靠日志猜。
真正难的不是怎么写 raise ... from，而是决定哪些异常值得封装、哪些该透传、哪些必须记录后重新抛出。这需要结合业务 SLA 和可观测性设计来定，不是纯语法问题。
