Java异常处理的目标是自愈而非简单捕获，需区分运行时与编译时异常并采取不同策略，结合try-catch-finally闭环、重试降级熔断机制及语义化自定义异常实现可控恢复。
Java异常处理不是“兜底打印堆栈”就完事，而是要让程序在出错时能判断、能响应、能恢复——捕获是起点，自愈才是目标。
明确异常类型，决定处理策略
捕获前先分清是运行时异常（如NullPointerException、ArithmeticException）还是编译时异常（如IOException、SQLException）。前者多由逻辑缺陷导致，应优先修复代码；后者常因外部依赖不稳定引起，更适合设计重试、降级或 fallback 机制。
- 对NullPointerException，优先用
Objects.requireNonNull()提前校验，而非等它抛出再捕获 - 对IOException，可配合
try-with-resources自动释放资源，并在 catch 中尝试重试或返回默认值 - 避免用
catch (Exception e)笼统捕获——掩盖真实问题，也阻碍针对性自愈
用 try-catch-finally 构建基础自愈链
一个完整的异常处理块，不只是“抓到就完”，而要形成“检测→干预→清理→续行”的闭环：
-
try中放核心业务逻辑，保持精简，不混入资源初始化或日志记录 -
catch里做三件事：记录可追溯的日志（含上下文参数）、执行补偿动作（如回滚事务、调用备用接口）、返回安全结果（如空集合、默认对象） -
finally专注资源释放，但注意：不要在其中写return，否则会吞掉原异常或返回值
引入自愈能力：重试、降级与熔断
对易受外部影响的操作（如 HTTP 调用、数据库查询），仅捕获不够，需叠加策略：
立即学习“Java免费学习笔记（深入）”；
- 简单重试：用
for循环 + 延迟（如指数退避），适用于瞬时网络抖动 - 服务降级：当主逻辑失败，自动切换到轻量实现（如缓存读取代替 DB 查询）
- 熔断保护：连续失败达阈值后，短时拒绝后续请求，避免雪崩——可用
Resilience4j或Hystrix实现
自定义异常增强语义与流程控制
系统级异常（如RuntimeException）缺乏业务含义，建议按场景定义异常类：
- 继承
RuntimeException（非检查异常），用于前端可感知的业务错误（如UserLoginFailedException） - 继承
Exception（检查异常），用于必须显式处理的关键路径异常（如InsufficientBalanceException） - 每个自定义异常携带状态码、用户提示文案、内部错误原因，便于统一响应封装和前端友好展示
