Java多catch核心是按业务语义分层捕获异常，子类异常须置于父类之前以确保精准匹配，每个catch应聚焦单一职责并直接完成对应响应，避免空catch或仅打印堆栈。
Java中用多个catch块处理不同异常，核心是让每种异常走专属逻辑，而不是全塞进一个通用兜底里。关键不是堆catch数量，而是按业务语义分层捕获——比如网络超时、数据格式错误、权限不足，各自响应方式完全不同。
按异常类型精准分流
多catch的本质是类型匹配，JVM从上到下逐个比对，一旦命中就执行对应块并跳过后续catch。所以必须把子类异常写在前面，父类放后面，否则子类永远没机会执行。
- 正确顺序示例：SocketTimeoutException → IOException → Exception
- 错误写法：把Exception放在最前，后面所有catch都失效
- 编译器会检查重复捕获，比如同时写NullPointerException和RuntimeException会报错
每个catch块聚焦单一职责
别在catch里写一堆if判断再分支处理——那等于退回单catch老路。每个catch应直接完成该异常场景下的完整响应动作。
- 捕获IllegalArgumentException：记录参数校验失败日志，返回400 Bad Request
- 捕获SQLException（SQLState以“23”开头）：识别为唯一约束冲突，返回409 Conflict
- 捕获HttpClientErrorException.Unauthorized：清空本地token，跳转登录页
避免吞掉异常或重复包装
细粒度不等于层层try-catch嵌套，更不是每个方法都加一堆catch。多数情况下，异常应在能决策如何响应的层级捕获，其他地方该抛就抛。
立即学习“Java免费学习笔记（深入）”；
- DAO层通常只抛出原始异常（如JDBC异常），不catch也不转成业务异常
- Service层根据上下文决定是否转成自定义异常（如UserNotFoundException），但不立即处理
- Controller层才用多catch做最终响应：HTTP状态码、错误码、提示文案各不相同
- 不要在catch里只写e.printStackTrace()或空catch，这会让问题隐身
配合try-with-resources与finally保持健壮
多catch常和资源管理共存。确保流、连接、锁等资源释放不依赖catch逻辑，否则异常干扰资源回收。
- 优先用try-with-resources自动关闭，比finally手动close更可靠
- 如果必须用finally，只做资源清理，别在里面throw新异常（会覆盖原异常）
- 需要记录异常又不想影响流程？用log.error("xxx", e)，而非log.error("xxx: " + e.getMessage())——后者丢失堆栈
