Java异常处理是程序状态流转的关键控制点，try-catch-finally构成轻量级状态机：try为“尝试执行”状态，异常触发跃迁至catch（“错误处理”）或finally（“终态保障”），finally确保资源终态不泄漏，catch需按具体异常类型决策状态走向，自定义异常可建模业务语义。
Java异常处理不是简单的“兜底代码”，而是程序状态流转的关键控制点。把try-catch-finally看作一种轻量级状态机，能更精准地设计容错逻辑、资源生命周期和业务流程分支。
try-catch-finally 本质是状态转移边界
每个try块定义了一个“可中断执行区间”，一旦抛出异常，就强制退出当前状态（try内剩余语句不执行），跳转到匹配的catch或finally——这相当于一次显式的状态跃迁。与if-else不同，这种跃迁由JVM统一调度，不可绕过，天然具备原子性和确定性。
- try开始：进入“尝试执行”状态
- 异常发生：立即终止当前状态，触发“异常捕获”或“清理过渡”状态
- catch匹配成功：进入“错误处理”状态（可继续抛出新异常，实现状态再跃迁）
- finally执行：无论前面什么状态，都必须进入“终态保障”状态（如关闭连接、释放锁）
用finally固化资源终态，避免状态泄漏
资源（文件、连接、锁）本质上是程序的外部状态。若只靠try/catch管理，一旦catch中再次抛异常或return，资源可能未释放——这就是状态泄漏。finally的作用，是把“释放资源”这个动作绑定到所有路径的终点，确保状态归零。
- 不要在finally里写业务逻辑，只做状态重置（close()、unlock()、reset()）
- 多个资源嵌套时，优先用try-with-resources（自动调用close()），它底层也是编译器生成finally逻辑
- 若手动管理，finally中需判空并捕获关闭异常（如IOException），避免掩盖主异常
catch块是状态决策点，不是日志打印区
一个catch不只是“抓住异常”，更是根据异常类型决定后续状态走向：重试、降级、告警、回滚、还是向上透传。设计时应明确每个catch对应的状态语义。
立即学习“Java免费学习笔记（深入）”；
- 捕获具体异常（如SQLException），而非笼统Exception，避免模糊状态意图
- 若需重试，应在catch内调用重试逻辑，而不是让异常穿透到上层——状态决策留在本层
- 对可恢复异常（如网络超时），catch后可返回默认值或缓存数据；对不可恢复异常（如参数校验失败），应包装为业务异常并throw，推动上游调整输入状态
结合自定义异常建模业务状态流
登录失败场景中，“用户名错误”和“密码错误”表面相似，但安全策略不同：前者可快速返回提示，后者需延迟响应防暴力破解。用不同自定义异常区分，就是为状态机注入语义。
- 定义LoginFailedException（基类）、UserNotFoundException、WrongPasswordException（子类）
- controller层catch UserNotFoundException，直接返回401；catch WrongPasswordException，记录失败次数并加延迟
- 这样异常类型本身就成了状态标识符，比if (code == 1001) 更具可读性和扩展性
