把自定义异常与异常链讲出实践味道，有一个可操作的公式：定义它的动机、携带哪些上下文、怎么和底层异常串成链、用错会怎样。四样凑齐，面试官才会觉得你真正在生产里踩过坑，而不是只背过"要自定义异常"这句话。每次面试讲到异常设计，都有人栽在"为什么不直接用 RuntimeException"这种追问上。这篇把这类追问提前标出来。
机制拆解
先把结论放在前面：自定义异常的价值在于给错误"分类"和"携带上下文"——让调用方能按类型精确捕获、让排查时能直接拿到订单号/用户 ID 等关键线索。异常链（cause 链）的价值在于不丢根因：把底层异常作为 cause 一路上抛，上层既能按自己的语义抛新异常，又能顺藤摸瓜找到最初的错误。这题要答好，关键是讲清"什么时候该自定义、怎么自定义才不添乱"。
这些坑的正确绕法
最常见的坑是搞了一堆自定义异常却只用 Exception 一把梭捕获。定义了一堆 UserException、OrderException，结果调用方全写成 catch (Exception e)，分类毫无意义，还不如不定义。自定义异常必须配合"按类型分别处理"才有价值：可重试的、需降级的、必须告警的，各归各的 catch，否则就是制造噪音。
其次是抛新异常时丢了 cause。把 SQLException 或 IOException 直接 throw new BizException("失败") 而没把原异常传进去，堆栈从这一层断掉，排查时只能看到业务层的"失败"，看不到底层的"连接超时"或"死锁"，根因被埋。正确的做法是 throw new BizException("下单失败, orderId=" + id, e)，把原异常作为 cause 一路带上去。
还有一个更隐蔽的坑：在异常里塞了不该序列化的字段，或重写了 message 却不带上下文。分布式系统里异常常常要跨网络传输、落日志、进监控，如果自定义异常持有大对象或无法序列化的资源，序列化时直接炸；message 里只写"出错了"三个字，告警出来没人知道是哪笔订单。异常是排查的第一现场，上下文缺失等于把第一现场清理干净了。
代码里见真章
看一段能直接跑的代码，把上面的机制落到具体写法上：
// 自定义业务异常：带错误码 + 上下文，且保持 cause 链
class OrderException extends RuntimeException {
final String orderId;
final int code;
OrderException(String orderId, int code, String msg, Throwable cause) {
super(msg, cause); // 关键：把底层异常作为 cause 传入
this.orderId = orderId;
this.code = code;
}
}
try {
pay(); // 内部可能抛 SQLException
} catch (SQLException e) {
// 上抛业务异常，保留根因 + 携带 orderId 便于排查
throw new OrderException(orderId, 5001, "支付失败", e);
}
// 上层可按类型精确捕获：重试 / 降级 / 告警
这段代码值得盯三处：第一处，自定义异常继承 RuntimeException（业务异常多为非受检，避免污染所有方法签名）；第二处，super(msg, cause) 把底层异常挂成 cause，堆栈链不断；第三处，构造时把 orderId、code 写进字段和 message，告警和日志里一眼定位。面试讲到这一层，基本就稳了。
这题在面试里怎么问、怎么答
"请简单介绍一下自定义异常与异常链，它们在 Android 开发中起什么作用？"按"是什么 → 干什么用 → 项目里怎么用"递进，别超三分钟。自定义异常用来给错误分类和携带上下文，异常链用来保留根因。在分层架构里，DAO 层的 SQLException 不该直接抛到 UI，而是包装成领域异常上抛，UI 层按类型决定展示"网络错误"还是"请重试"。如果要把异常设计沉淀成团队规范，建议加两条硬约定：一是业务异常必须带可定位上下文，二是上抛时需要保留 cause。
"它们的底层原理是什么？能不能详细说一下？"异常链本质是 Throwable 里那个 cause 字段——getCause() 顺着它一路往回追溯，打印堆栈时 JVM 会递归打印 cause 的堆栈，于是你能看到完整链路。initCause() 和带 cause 的构造器是同一个字段的两种写入方式，后者更常用。机制别空讲，配核心片段最稳——包装时记得把原异常作为 cause 传入，否则根因链断裂。如果讲给新人，从一个"catch 丢 cause 导致排查三天"的反例切入。
"在使用自定义异常时遇到过什么问题？"讲真实案例：现象、定位、修复、验证。比如某次线上偶发订单状态错乱，最终定位到是某层把底层异常吞了、只抛了个无上下文的"处理失败"，排查花了很久。修复是统一换成带 cause 和 orderId 的 OrderException，并加监控按 code 聚合。数字化的修复效果（平均排障时间从 X 小时降到 Y）最加分。
"它们和相关的替代方案相比，有什么优劣？"与直接用 ErrorCode 返回相比，异常能把错误从正常返回路径分离、强制处理、带堆栈；与只用 RuntimeException 不分类相比，自定义异常能精确捕获、语义清晰。代价是定义和维护成本，以及不当使用（如类型泛滥、丢 cause）反而添乱。选型就按"性能、易用性、生态、成本"四项来，没有万能答案：能说清什么场景用什么，才叫真懂。选型时要把"抛新异常不传 cause，根因被埋"这类代价摆到台面上。
把异常设计再往前推一步：当业务异常种类变多时，建议做一层"异常层次"而非一堆平铺的类——比如定义 BizException 作为基类，下面按领域分 OrderException、PayException，再按处理方式分"可重试""需降级""致命"的标记接口或枚举。这样上层既能按基类兜底，又能按子类精确处理。另一个工程要点是异常信息要"自解释"且"可聚合"：message 里带上 orderId、code、关键上下文，监控按 code 聚合后就能直接看出哪类故障在涨。日志框架配合 MDC 还能把 traceId 自动带进每一条异常日志，跨服务排查时串联全链路。异常不是写完就完事，它是线上可观测性的第一现场，设计得好能让排障时间从小时级降到分钟级。
还有一个常被问到的取舍：自定义业务异常该继承 Exception（受检）还是 RuntimeException（非受检）。经验法则倾向于非受检——业务异常大多"调用方无法合理恢复"，强制 throws 只会污染整条调用链的方法签名，让代码充斥声明。真正需要调用方必须处理的（如资源不可用、参数非法需修正），才考虑受检。另一点是异常不要用来做正常的"分支返回"：当某个结果属于正常业务分支（如"用户不存在"），用 Optional 或 Result 返回比抛异常更清晰，也避免把控制流伪装成错误流。异常与返回值的边界划清，代码语义才不会被混淆。
给正在准备面试的你
把自定义异常与异常链的要点放进一次真实编码练习：写一个分层调用，让底层抛受检异常，中间层包装成带 cause 和上下文的业务异常，上层按类型分别处理。面试中关于异常设计的问题，关键在于能够从原理、应用、踩坑三个层面给出有深度的回答。
再补工程案例与踩坑——应用落点是梳理项目里三类异常的处理策略：可恢复（带 retry 标记）、可降级（带 fallback）、必须上抛（带上下文），并给出代码骨架，避免"一把梭 catch Exception"。
复习时别孤立刷题：HashMap 底层原理——数组、链表与红黑树的演进相邻考点是一串的，面试常打包出现。
划两句重点：自定义异常的价值是分类 + 携带上下文，不是越多越好；异常链的核心是保留 cause，丢 cause 等于切断根因。
下一篇聊泛型基础：类型擦除到底擦了什么——沿着今天这条主线继续往前走。
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。你的支持就是这个系列持续更新的动力。
「Android软件开发面试·从入门到精通」连载系列
上一篇：try-catch-finally-与-try-with-resources：资源释放正确姿势
下一篇预告：泛型基础：类型擦除到底擦了什么
有任何问题欢迎在评论区留言交流。
