Java · 异常体系与实践

场景 1 · @ControllerAdvice 统一异常出口, 响应里带 request_id

几十个 Controller 各自 try/catch 返回五花八门的错误体, 前端没法写统一拦截; 收口到一个出口, 异常翻译成 HTTP 码 + 错误码 + 排障号:

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(BizException.class)          // 业务错: 4xx, warn 级
    public ResponseEntity<ErrorResp> biz(BizException e, HttpServletRequest req) {
        log.warn("rid={} code={}", req.getAttribute("request_id"), e.getCode());
        return ResponseEntity.status(e.getHttpStatus())
            .body(new ErrorResp(e.getCode(), e.getUserMessage(), rid(req)));
    }

    @ExceptionHandler(Exception.class)             // 兜底: 500, 不打栈=丢现场
    public ResponseEntity<ErrorResp> unknown(Exception e, HttpServletRequest req) {
        log.error("rid={} unhandled", rid(req), e);    // e 必须是最后一个参数
        return ResponseEntity.internalServerError()
            .body(new ErrorResp("INTERNAL_ERROR", "系统繁忙, 请稍后再试", rid(req)));
    }
}

改造后前端只认一种错误体; 线上告警按 rid 一键捞出完整调用链。

场景 2 · 业务异常基类: 错误码 + 用户消息 + 上下文字段

裸 RuntimeException 只有一个字符串, 排障全靠猜; 基类把"机器可判的码"和"人可读的话"分开存:

public class BizException extends RuntimeException {
    private final String code;        // 稳定错误码: ORDER_STOCK_NOT_ENOUGH, 程序判分支用
    private final String userMsg;     // 可直接透出的用户文案
    private final Map<String, Object> ctx;  // 排障上下文: skuId/want/left

    public BizException(ErrorCode ec, Map<String, Object> ctx, Throwable cause) {
        super(ec.getCode() + ": " + ec.getUserMsg() + " ctx=" + ctx, cause); // message 自带现场
        this.code = ec.getCode(); this.userMsg = ec.getUserMsg();
        this.ctx = ctx == null ? Map.of() : Map.copyOf(ctx);
    }
}
// 抛出: throw new BizException(ErrorCode.STOCK_SHORT,
//         Map.of("skuId", skuId, "want", n, "left", stock), null);

场景 3 · 高频脏数据探测: 无栈哨兵异常, 百万次/秒不崩

风控前置的行级校验, 脏数据占比 30%, 每秒百万行; 普通 Exception 每次构造抓 80 帧栈, CPU 全烧在 fillInStackTrace:

// 预分配一次的哨兵: 无栈, 单例, 类型即信号
static final DirtyLineError DIRTY = new DirtyLineError();
static class DirtyLineError extends RuntimeException {
    @Override public synchronized Throwable fillInStackTrace() { return this; }
}
for (byte[] line : partition) {
    if (!quickCheck(line)) throw DIRTY;   // 调用方 catch 类型后走拒绝分支
}
// 压测量级: 抓栈版 ~1.2μs/次 × 100万/s ≈ 独占 1 个核; 无栈版 ~15ns, 百万次仅 15ms
// 注意: 哨兵不带现场 — 脏行号在调用方自己记录, 别指望异常告诉你

改造后该阶段 CPU 占比从 38% 降到 1% 以内, 与返回布尔值方案几乎打平。

场景 4 · CompletableFuture 的异常传播: exceptionally / handle

异步链里任何一步抛异常都会短路后续 thenApply, 但不接住就静默蒸发:

CompletableFuture<Price> f = fetchAsync(skuId)
    .thenApply(this::normalize)
    .exceptionally(e -> {                          // 只管异常分支, e 是 CompletionException 包装
        if (e.getCause() instanceof TimeoutException) return Price.FALLBACK;
        throw new CompletionException(e);           // 不认识的继续外抛, 别在这吞
    });
// 正常/异常都要处理用 handle((v, e) -> ...); exceptionally 只是它的单臂版
// 多个 future 汇聚: anyOf/allOf 抛出的是首个失败, 同样要 getCause 拆包

场景 5 · 线程池任务异常默认被吞: 三种收尸方式

execute 提交的任务抛了异常, 控制台一闪而过(甚至什么都不留), 告警全无 — 这是定时任务"静默停摆"的头号原因:

pool.execute(() -> { throw new IllegalStateException("boom"); }); // 无声消失!

// 方式1: submit + get — 异常在 get() 处重新抛出
pool.submit(task).get(5, TimeUnit.SECONDS);

// 方式2: 装饰 Runnable, 把 execute 路径的异常送进处理器
static Runnable wrap(Runnable r) {
    return () -> { try { r.run(); }
             catch (Throwable t) { log.error("task failed", t); metrics.tick(t); } };
}
// 方式3: 覆写 afterExecute 收集 Throwable 参数 (定时任务强依赖这层兜底)

补充: scheduleAtFixedRate 的任务抛出未捕获异常后整条调度静默死亡 — 任务体内必须自 catch。

场景 6 · 分布式锁做成 AutoCloseable, 跟 try-with-resources 走

手写 lock/unlock 配 finally, 早 return/异常路径漏 unlock 的 review 根本盯不住; 把锁变成资源:

class RedisLock implements AutoCloseable {
    private final String key, token;
    RedisLock(RedisClient cli, String bizKey, Duration lease) {
        this.key = "lock:" + bizKey;
        this.token = cli.setNxPx(key, UUID.randomUUID().toString(), lease);  // 抢锁
    }
    @Override public void close() {                       // 编译器保证调用
        client.releaseIfOwner(key, token);    // Lua 比对 token 才删, 防误删别人的锁
    }
}
// 用法: pay 抛任何异常, 锁都自动释放, 不用手写 try/finally
try (RedisLock lk = new RedisLock(cli, "order:" + oid, Duration.ofSeconds(5))) {
    pay(oid);
}

场景 7 · 异常翻译层: SQLException → 语义异常

底层厂商错误码不该漏进业务代码; 在 DAO 边界统一翻译, 上层只面对语义 (Spring 的 DataAccessException 就是这套思路):

public <T> T query(String sql, RowMapper<T> mapper) {
    try { return doQuery(sql, mapper); }
    catch (SQLException e) {
        switch (e.getErrorCode()) {                  // 厂商码 → 统一语义
            case 1062: throw new DuplicateKeyException(sql, e);    // 唯一键冲突, 可转用户提示
            case 1205: throw new LockWaitTimeoutException(sql, e); // 锁超时, 可重试
            default:   throw new DataAccessResourceException(sql, e);
        }   // 注意每个翻译分支都把 e 传成 cause — 保住原始现场
    }
}

换 MySQL → PostgreSQL 只改翻译层, 业务代码零改动; 重试策略也能按语义类型声明。

场景 8 · 重试框架只重试"可重试异常"

无脑重试把 4xx 参数错误也放大三倍流量, 还把故障雪崩拉长; 分类放在异常基类上, 调用方零 if-else:

abstract class RpcException extends RuntimeException {
    abstract boolean retryable();             // 由子类声明语义
}
public <T> T retry(String op, Supplier<T> call) {
    for (int i = 0; ; i++) {
        try { return call.get(); }
        catch (RpcException e) {
            if (!e.retryable() || i == 3) throw new GiveupAfterRetry(op, i, e); // 带次数+操作名
            sleep(backoffWithJitter(i));         // 指数退避+抖动, 防同步重试风暴
        }
    }
}
// TimeoutException→retryable=true; InvalidParamException→false, 重试只会放大故障

场景 9 · 全局 UncaughtExceptionHandler 兜底 worker 线程死亡

队列消费线程被一个 NPE 干掉后, 进程还活着、健康检查还绿 — 数据却不再流动; 兜底 + 上报让"死线程"变成告警:

Thread.setDefaultUncaughtExceptionHandler((t, e) ->
    reporter.fatal("uncaught thread=" + t.getName(), e));  // 任何漏网异常都到这

Thread worker = new Thread(() -> {
    while (running) {
        try { consume(queue.take()); }
        catch (InterruptedException ie) { Thread.currentThread().interrupt(); return; }
        catch (Throwable t) { log.error("msg dropped, loop continues", t); } // 单条失败不退循环
    }
}, "order-consumer");
worker.start();   // 若不 catch: 一条毒消息就让整条消费线静默死亡

场景 10 · 断言式参数校验, 干掉五层 if 嵌套

手写 if-return-null 的卫语句金字塔, 三个月后没人敢动; 平铺断言让"入口即校验失败即抛":

public Order create(CreateOrderCmd c) {
    require(c.getUserId() != null, "userId required");   // 一行一断言, 顶部平铺
    require(c.getSkuId()   != null, "skuId required");
    require(c.getQty()     > 0,    "qty must be positive");
    return doCreate(c);       // 到这里参数一定是干净的, 主逻辑零防御分支
}
static void require(boolean ok, String msg) {
    if (!ok) throw new IllegalArgumentException(msg + " at OrderService.create"); // 标注出错位置
}
// 同族: Objects.requireNonNull / Spring Assert / Guava Preconditions — 只选一种, 全队统一