Java异常处理的核心是将错误转化为可控、可读、可恢复的行为，其关键在于区分Error、受检异常和RuntimeException三类，合理使用try-catch-finally、throws/throw，并通过自定义异常明确业务语义。
Java异常处理机制的核心是把“出错”变成可控、可读、可恢复的行为，而不是让程序突然中断或用一堆if判断掩盖问题。它不是锦上添花的语法糖，而是构建健壮程序的基础能力。
搞清异常的三类角色：Error、Exception、RuntimeException
所有异常都源自Throwable，但实际开发中只需重点区分三类：
-
Error：JVM级严重问题，比如
OutOfMemoryError、StackOverflowError。不建议捕获，也无法靠代码逻辑修复，应通过调优内存、限制递归深度等方式预防。 -
受检异常（Checked Exception）：编译器强制你处理的异常，典型如
IOException、SQLException。它们反映的是外部不确定性（文件可能被删、网络可能断开），程序无法完全控制，但可以响应——重试、提示用户、切换备用路径等。 -
运行时异常（RuntimeException）：比如
NullPointerException、ArrayIndexOutOfBoundsException、ArithmeticException（除零）。编译时不强制处理，但本质是代码缺陷，应通过逻辑校验提前规避，而非依赖catch兜底。
掌握 try-catch-finally 的真实作用边界
这不是“把报错代码包起来就安全了”的万能套壳，关键在职责分明：
-
try块只放真正可能抛异常的语句，比如
new FileInputStream("a.txt")或Integer.parseInt(str)；别把整个业务逻辑塞进去。 -
catch要抓具体类型，避免写
catch(Exception e)。先捕子类（如FileNotFoundException），再捕父类（如IOException），否则子类永远匹配不到。 -
finally不是“收尾仪式”，而是资源释放的刚性保障：流、连接、锁等必须关闭的资源，放在这里最稳妥。Java 7+ 推荐用
try-with-resources自动管理，更简洁可靠。
理解 throws 和 throw 的分工逻辑
这两个关键字解决的是“谁该负责处理异常”的权责划分问题：
立即学习“Java免费学习笔记（深入）”；
- throws写在方法声明后，是对外的契约声明：“我这个方法可能会出XX异常，请调用者做好准备”。对受检异常，这是编译强制要求；对运行时异常，加不加纯属提示，不影响编译。
- throw写在方法体内，是主动制造异常对象并中断执行。“throw new IllegalArgumentException("id不能为负")”不是报错，而是用异常表达业务规则——比返回错误码更清晰、更难被忽略。
自定义异常让错误语义真正落地
系统异常描述太泛，比如IllegalArgumentException无法说明“为什么参数非法”。这时继承Exception（受检）或RuntimeException（非受检）创建专属异常：
- 命名体现业务场景，如
InsufficientBalanceException、InvalidOrderStatusTransitionException； - 构造函数支持传入原始异常（cause），方便保留完整调用链；
- 配合日志输出和监控告警，能让运维快速定位是哪类业务失败，而不是在一堆
NullPointerException里大海捞针。
