多catch块是防御性编程关键手段，通过精准识别、分类响应和及时止损将崩溃点转化为可干预节点；须按异常具体性从高到低排列，JVM自上而下匹配，通用异常不可前置；支持竖线合并同质异常；应使用领域语义化异常替代泛化捕获；资源清理需协同设计，优先用try-with-resources。
多catch块本身不直接“控制系统脆弱性”，但它是一种关键的防御性编程手段——通过精准识别、分类响应和及时止损，把潜在的运行时崩溃点转化为可观察、可干预、可恢复的业务节点。
按异常具体性从高到低排列
这是多catch最基础也最关键的规则。JVM匹配catch块是自上而下线性扫描，一旦命中就停止。如果把通用异常（如Exception）写在前面，所有子类异常（比如SQLException、FileNotFoundException）都会被提前拦截，变成不可达代码，编译直接失败。
- 正确顺序示例：FileNotFoundException → IOException → Exception（兜底）
- 文件上传场景中，先捕获FileNotFoundException说明路径错误；再捕获SecurityException说明权限不足；最后用Exception兜住未预期的逻辑异常，但不掩盖前两者语义
- 避免把RuntimeException和它的子类（如NullPointerException）混在同一层级处理——它们本就不强制声明，更需靠前置校验+精准捕获来暴露问题根源
同质异常合并处理，减少冗余分支
当几种异常在业务层面意味着同一类失败（比如网络调用中SocketTimeoutException、ConnectException、UnknownHostException都代表“下游暂时不可达”），没必要为每个写一个catch块。
- Java 7+支持竖线语法：catch (SocketTimeoutException | ConnectException | UnknownHostException e)
- 注意：这些类型不能有继承关系。例如不能写FileNotFoundException | IOException，因为前者是后者子类，编译报错
- 合并后统一执行降级逻辑——返回缓存数据、触发熔断、记录监控指标，而不是重复写三遍几乎一样的日志和告警
用领域语义化异常替代泛化捕获
依赖catch (Exception e)就像给所有故障贴同一个标签：“出错了”。它掩盖了真实原因，也让调用方无法决策——是重试？跳过？还是提示用户修改输入？
立即学习“Java免费学习笔记（深入）”；
- 定义明确业务含义的异常类，例如InsufficientStockException、InvalidPaymentTokenException
- 在catch中包装再抛出，带上上下文：throw new InsufficientStockException("SKU " + skuId + " 库存不足", orderId, skuId);
- 上层可通过instanceof或统一异常处理器分流：库存不足走补货流程，支付凭证失效则引导用户重新授权
资源清理必须与异常捕获协同设计
多catch解决了“怎么响应”，但没解决“出错后状态是否干净”。一个未关闭的数据库连接、未释放的文件句柄，本身就是系统脆弱性的放大器。
- 优先使用try-with-resources自动管理实现AutoCloseable的资源，比手动finally更可靠
- 若需在catch中做补偿（如回滚事务、发告警），确保该操作本身不抛新异常干扰主流程；必要时用try-catch包裹补偿逻辑
- 不要在finally里放可能失败的操作（比如再次close一个已关闭的流），否则会覆盖原始异常，导致根因丢失
本质上，多catch不是堆砌防御层，而是构建异常响应的路由表——让每种失败信号都能导向最匹配的处置动作。它不消除脆弱性，但让脆弱点变得透明、可控、可演进。
