Python自定义异常应继承Exception或其子类，实现__init__方法传递参数并生成清晰错误消息；Java需区分checked/unchecked异常，业务规则错误用RuntimeException子类；Go通过实现error接口的结构体携带上下文；跨服务需统一错误码而非仅HTTP状态码或消息文本。
Python 里怎么定义一个自定义异常类
直接继承 Exception 或它的子类（比如 ValueError），别用 BaseException —— 那是系统级异常的父类，乱继承会导致 Ctrl+C 失效、程序无法正常退出。
常见错误是只写个空类，结果抛出时没提示信息，调试时一脸懵：
class InvalidOrderStatus(Exception):
pass
raise InvalidOrderStatus() # ❌ 没消息，看不出哪错了
实操建议：
- 在
__init__里接收必要参数，拼成清晰的错误消息，比如订单 ID、当前状态 - 如果需要额外字段（如错误码、关联数据），加为实例属性，方便上层捕获后结构化处理
- 类名用大驼峰，且以
Error或Exception结尾，符合 Python 社区惯例（如PaymentTimeoutError）
class PaymentTimeoutError(Exception):
def __init__(self, order_id: str, timeout_seconds: int):
self.order_id = order_id
self.timeout_seconds = timeout_seconds
super().__init__(f"Payment for order {order_id} timed out after {timeout_seconds}s")Java 中 throw 自定义异常要注意什么
Java 分检查型（checked）和非检查型（unchecked）异常，选错类型会强迫调用方写一堆 try-catch 或声明 throws，反而破坏业务逻辑流。
典型误用：把本该快速失败的参数校验错误（如 userId == null）做成 checked 异常，结果每个 service 方法头都堆着 throws UserInvalidException。
实操建议：
- 业务规则违反（如“余额不足”“库存超限”）用 unchecked：继承
RuntimeException - 外部依赖故障（如“短信网关不可达”“下游 HTTP 超时”）可考虑 checked，但得确认调用方真能恢复
- 所有自定义异常类必须有带
String的构造函数，否则throw new XxxException("msg")编译不过
public class InsufficientBalanceException extends RuntimeException {
public InsufficientBalanceException(String message) {
super(message);
}
// 推荐再加一个带 cause 的构造函数，方便链式异常封装
public InsufficientBalanceException(String message, Throwable cause) {
super(message, cause);
}
}Go 里没有传统异常，那怎么表达业务错误
Go 用 error 接口 + 值判断，不是靠类型继承。所以“自定义异常”其实是实现 Error() 方法的结构体，重点在错误分类和上下文携带，而不是 try-catch 流程。
容易踩的坑是只返回 fmt.Errorf("xxx")，导致上层只能字符串匹配，一改文案就崩；或者用 errors.New 硬编码，丢失关键字段。
实操建议：
- 定义结构体，内嵌必要字段（如订单号、错误码
ErrCode），实现Error()方法 - 用
errors.Is()和errors.As()判断类型或提取上下文，别用==或strings.Contains() - 如果要包装底层错误（比如 DB 查询失败），用
fmt.Errorf("xxx: %w", err)保留原始 error 链
type InventoryShortageError struct {
OrderID string
SKU string
Needed int
}
func (e *InventoryShortageError) Error() string {
return fmt.Sprintf("inventory shortage for order %s, SKU %s, needed %d",
e.OrderID, e.SKU, e.Needed)
}
// 使用
if stock < needed {
return nil, &InventoryShortageError{OrderID: oid, SKU: sku, Needed: needed}
}
跨服务传递自定义错误时最常漏掉的事
HTTP API 返回 500 Internal Server Error 并附一段 JSON 错误消息？这等于把自定义异常降级成了日志文本——调用方拿不到类型、无法做差异化重试或降级，连告警都难打标签。
真正要传递的是语义化的错误标识，不是堆栈或消息原文。
实操建议：
- 定义统一错误码体系（如
"ORDER_STATUS_INVALID"），在响应体中固定字段返回（如error_code），不依赖 HTTP 状态码区分业务错误 - 避免在错误消息里拼接敏感数据（用户手机号、金额），消息只描述问题，细节走独立字段（
debug_id、trace_id） - gRPC 场景下，用
Status的Code+Details（protobuf Any 类型）传结构化错误，比纯字符串可靠得多
复杂点在于：同一错误在不同协议层表现形式不同，但核心错误标识必须一致。否则前端按 error_code 做 toast，移动端却在解析 message 字段，改一处漏三处。
