应按异常类型分层捕获：先业务异常（如accountnotfoundexception），再可重试i/o异常（如ioexception），最后runtimeexception；禁用catch(exception e)；自定义异常需语义明确、带错误码和可重试标识；资源关闭用try-with-resources；@exceptionhandler须匹配http状态码，避免全兜底。
按异常类型分层捕获，别用一个 catch (Exception e) 包打天下
Java 异常体系里，RuntimeException 及其子类是 unchecked，其他（如 IOException、SQLException）是 checked。这两类异常的处理意图完全不同：前者多反映程序逻辑缺陷（如 NullPointerException），后者往往对应可恢复的外部故障（如网络超时、文件不存在）。
常见错误是写成这样：
try {
doSomething();
} catch (Exception e) {
logger.error("出错了", e);
throw new ServiceException("操作失败");
}这会把 IllegalArgumentException 和 SocketTimeoutException 一锅端，掩盖了问题性质。正确做法是显式分层：
- 先捕获具体业务异常（如
AccountNotFoundException），走定制化响应（HTTP 404 + 提示文案） - 再捕获可重试的 I/O 异常（如
IOException），考虑降级或重试逻辑 - 最后用
catch (RuntimeException e)拦住未预期的编程错误，记录堆栈并返回 500 - 避免捕获
Exception或Throwable，除非在最外层统一兜底（如 Spring 的@ControllerAdvice）
自定义异常要带语义，别只是包装 Exception
直接继承 Exception 或 RuntimeException 不够——关键是要让调用方能靠类型判断“接下来该做什么”。比如 InsufficientBalanceException 和 InvalidCurrencyException 都属于支付失败，但前端提示、是否允许重试、是否触发告警，都应不同。
立即学习“Java免费学习笔记（深入）”；
实操建议：
- 异常类名必须表明失败原因和边界（如
PaymentTimeoutException而非PaymentException） - 构造函数接受原始异常（
cause）并保留堆栈，便于排查链路 - 可加字段（如
errorCode、retryable），但避免在异常里放业务数据（如用户 ID）——这些应通过日志或上下文传递 - Spring 项目中，配合
@ResponseStatus直接绑定 HTTP 状态码，比在 controller 里 if-else 判断更清晰
不要在 finally 里吞掉异常或覆盖原异常
典型反模式：
Connection conn = null;
try {
conn = dataSource.getConnection();
// ... 执行 SQL
} finally {
if (conn != null) {
try {
conn.close(); // 这里抛出 SQLException
} catch (SQLException e) {
logger.warn("关闭连接失败", e); // 吞掉！
}
}
}如果 try 块里已抛出 SQLException，finally 中再抛异常会覆盖原始异常，导致根因丢失。
正确做法：
- 用 try-with-resources（JDK 7+），自动抑制次要异常（
addSuppressed）并保留主异常 - 若必须手动关资源，
finally中的 close 操作也需 try-catch，且不能throw或return - 绝不写
catch (Exception e) { /* 什么也不做 */ }—— 至少记一条 warn 日志
Spring 中用 @ExceptionHandler 统一收敛，但别让它变成异常黑洞
@ControllerAdvice + @ExceptionHandler 是集中处理的好方式，但容易滑向“全收全转”的陷阱：所有异常都转成 ErrorResponse 并返回 200，掩盖了 HTTP 状态码语义。
要点：
- 为不同异常类型配不同状态码：
@ExceptionHandler(NotFoundException.class)→@ResponseStatus(HttpStatus.NOT_FOUND) - 避免在 handler 里重新 throw 新异常（如
throw new RuntimeException("包装一下")），这会让外层兜底逻辑重复处理 - 慎用
@ExceptionHandler(Exception.class)：它会吃掉你精心设计的细粒度 handler，应放在最末尾，且只做日志和兜底响应 - 如果异常需要异步通知（如发告警）、或触发补偿事务，别塞进 handler——用事件机制（如
ApplicationEventPublisher）解耦
异常策略最难的不是写多少 catch，而是判断哪一层该终止传播、哪一层该转换语义、哪一层该静默消化。多数线上问题，根源不在没捕获，而在捕获后做了错误的决策。
