企业官网建设流程全解析

Java 的异常（Exception）体系是语言最核心的工程能力之一：它决定了错误如何表达、如何传播、如何被定位与恢复。写出“可维护、可诊断、可扩展”的 Java 代码，异常设计和处理能力往往是分水岭。

本文从异常体系结构讲起，覆盖：Checked/Unchecked 的本质差异、try-catch-finally 细节、try-with-resources、异常链、常见反模式、业务异常设计、日志与统一处理等高频面试 + 实战内容。

1. 异常是什么？为什么需要异常机制

异常（Throwable）本质是：程序运行过程中出现了非预期状态，需要一种机制把“错误”从局部传递到上层，并携带足够的诊断信息（类型、堆栈、消息、原因）。

相比返回错误码，异常机制的优势：

• 能携带调用栈（定位成本低）

• 支持分类（类型系统驱动处理策略）

• 支持异常链（保留根因）

• 强制/约束处理（Checked 异常）

2. Java 异常体系总览（Throwable 树）

Java 异常顶层父类：java.lang.Throwable，主要分两大分支：

• Error：严重问题，通常不可恢复（如 JVM 内存溢出、类加载错误）。一般不捕获或不做业务兜底恢复。

• Exception：可处理的异常。Exception 下面再分：

  • Checked Exception（受检异常）：必须显式处理（try-catch 或 throws）

  • Unchecked Exception（非受检异常）：RuntimeException及其子类，编译器不强制处理

记忆口诀：
Error 不管，Exception 要管；RuntimeException 不强制管。

3. Checked vs Unchecked：本质区别与工程取舍

3.1 Checked（受检异常）

典型：IOException,SQLException

特点：

• 编译器强制处理：不处理就编译不过

• 适合“调用方可能合理恢复”的场景：如读文件失败可以换路径/重试/降级

代价：

• 在层层调用中会导致“throws 传染”

• 容易出现大量样板代码（try-catch/throws）

3.2 Unchecked（非受检异常）

典型：NullPointerException,IllegalArgumentException,IndexOutOfBoundsException

特点：

• 不强制处理

• 更适合：编程错误、参数非法、状态不一致等“应当修代码而非恢复”的问题

3.3 实战建议（重要）

• 业务校验失败、用户输入错误、业务规则不满足：通常用自定义运行时异常（Unchecked）

• 外部依赖失败（IO、网络、DB）且调用方确实可恢复：可以保留 Checked，或在边界层转为业务异常

• 在服务端工程（Spring Boot）中更常见的实践是：
  底层异常统一包装为业务运行时异常 + 全局异常处理（便于统一返回、统一日志、减少 throws 传染）

4. try-catch-finally 语义细节（面试高频）

4.1 finally 一定会执行吗？

一般情况下：会执行（无论是否抛异常、是否 return）。

但以下情况 finally 可能不执行：

• System.exit()直接终止 JVM

• JVM 崩溃（如致命错误）

• 线程被强制杀死（极端情况）

4.2 catch 顺序：从子类到父类

否则会编译错误（父类捕获会吞掉子类分支）。

try { // ... } catch (NullPointerException e) { // 子类 } catch (RuntimeException e) { // 父类 }

4.3 finally 里不要 return / throw（非常重要）

finally 里的 return 会覆盖try/catch 的返回值或异常，导致排查地狱。

public int bad() { try { return 1; } finally { return 2; // 覆盖 try 的返回 } }

5. try-with-resources：资源关闭的最佳方式

JDK 7 引入，专为实现AutoCloseable的资源（流、连接、文件句柄等）设计，自动 close，且能正确处理 close 时的异常抑制（suppressed）。

try (BufferedReader br = new BufferedReader(new FileReader(path))) { return br.readLine(); } catch (IOException e) { throw new RuntimeException("读取文件失败", e); }

5.1 suppressed 异常是什么？

当 try 块抛异常，close 又抛异常，close 异常会被记录为suppressed，主异常仍保留，利于排查。

Throwable[] suppressed = e.getSuppressed();

6. 异常链（Cause）与“保留根因”原则

真实系统里，异常往往层层包装。最佳实践：包装异常时一定要把 cause 传进去。

正确：

catch (IOException e) { throw new BizException("文件服务不可用", e); }

错误（丢失堆栈与根因）：

catch (IOException e) { throw new BizException("文件服务不可用"); }

定位问题时最值钱的是：原始异常类型 + 堆栈 + 触发点。

7. 自定义业务异常：高质量设计模板

7.1 为什么要自定义业务异常？

• 把“可预期的业务失败”与“系统故障”区分开

• 便于统一返回码、统一错误信息

• 便于全局处理与统计监控

7.2 推荐结构：错误码 + 可读消息 + 可选上下文

public class BizException extends RuntimeException { private final String code; public BizException(String code, String message) { super(message); this.code = code; } public BizException(String code, String message, Throwable cause) { super(message, cause); this.code = code; } public String getCode() { return code; } }

进一步优化（可选）：

• code 用枚举统一管理

• message 走国际化（i18n）

• 附带 context（如订单号、用户 id），但注意隐私与安全

8. Spring/Spring Boot 项目中的统一异常处理（常用范式）

常见做法：使用@RestControllerAdvice+@ExceptionHandler统一返回结构。

@RestControllerAdvice public class GlobalExceptionHandler { @ExceptionHandler(BizException.class) public ResponseEntity<?> handleBiz(BizException e) { // 业务异常：可控，不打 full stack 或按需打印 return ResponseEntity.badRequest().body( Map.of("code", e.getCode(), "msg", e.getMessage()) ); } @ExceptionHandler(Exception.class) public ResponseEntity<?> handleOther(Exception e) { // 系统异常：必须记录堆栈 // log.error("系统异常", e); return ResponseEntity.status(500).body( Map.of("code", "SYSTEM_ERROR", "msg", "系统繁忙，请稍后再试") ); } }

工程建议：

• 业务异常：一般不需要打印成 ERROR 大堆栈（防止日志噪音），可按 warn/info，或打印摘要

• 系统异常：必须带堆栈 + traceId（链路追踪）

• 返回给用户的信息要“友好且不泄露内部细节”

9. 异常处理的经典反模式（高频踩坑）

9.1 catch (Exception) 然后什么都不做（吞异常）

try { doSomething(); } catch (Exception e) { // ignore }

危害：问题静默，线上数据错了你都不知道。

9.2 用异常做正常流程控制

比如用try/catch判断 map 是否有 key，或用捕获 NPE 当作 if。
异常很贵（构造堆栈开销大），而且可读性差。

9.3 只打印 e.getMessage() 不打印堆栈

堆栈才是定位关键。

• 正确：log.error("xxx", e);

• 错误：log.error(e.getMessage());

9.4 捕获后丢失 cause

见前文异常链。

9.5 finally 里做关键业务逻辑

finally 适合做资源释放、清理动作。关键逻辑放 finally 容易被覆盖/吞异常/难维护。

10. 常见运行时异常速查（附触发原因与建议）

• NullPointerException：对象为空仍调用方法/字段
  建议：参数校验、Optional（慎用）、合理默认值、提前失败

• IllegalArgumentException：方法参数非法
  建议：对外接口优先抛它或 BizException

• IllegalStateException：对象状态不对
  建议：状态机/流程控制要清晰

• ClassCastException：类型转换错误
  建议：泛型、instanceof、避免 raw type

• NumberFormatException：字符串转数字失败
  建议：输入校验、异常转换为业务提示

• IndexOutOfBoundsException：索引越界
  建议：边界判断

11. 如何写出“可诊断”的异常信息（日志与消息技巧）

高质量异常信息 =发生了什么 + 为什么 + 影响什么 + 关键上下文

示例：

• “下单失败”

• “下单失败：库存不足，sku=xxx, need=3, left=1, orderId=xxx”

注意：

• 不要把敏感信息写入异常 message 和日志（如密码、token、完整身份证号）

• 上下文信息建议通过结构化日志字段（traceId、userId、orderId）输出

12. 一套推荐的异常分层策略（适合大多数后端项目）

按层思考：

1. DAO/Client 层（DB/HTTP/IO）：抛出原始异常或封装成基础设施异常

2. Service 层：将外部异常转换为业务可理解的 BizException（保留 cause）

3. Controller/网关层：统一异常处理 + 返回统一格式 + 统一日志策略

目标：

• 业务代码不被大量 try-catch 污染

• 异常含义清晰、定位方便

• 用户返回安全、可控

13. 总结（建议收藏的要点清单）

• Throwable 分 Error/Exception，Exception 分 Checked/Unchecked

• 受检异常强制处理，非受检异常更适合编程错误与业务失败

• finally 不要 return/throw；catch 顺序从子类到父类

• 资源关闭优先用 try-with-resources

• 包装异常一定传 cause，保留根因与堆栈

• 业务异常建议：错误码 + message + 可选上下文

• Spring 常用：@RestControllerAdvice 做统一异常处理

• 避免吞异常、避免用异常做流程控制、日志要打印堆栈

• 异常信息要可诊断，但不要泄露敏感信息