Java编译器要求catch块按异常继承关系从具体到宽泛排列，否则子类异常会被父类Exception提前捕获，导致后续catch块不可达而编译失败。
因为 java 编译器要求 catch 块必须按异常类型继承关系从具体到宽泛排列，exception 作为绝大多数异常的顶层父类，一旦写在前面，就会提前捕获所有子类异常（包括并发相关的 interruptedexception、timeoutexception、executionexception 等），导致后续更具体的 catch 块变成不可达代码，编译器直接拒绝通过。
编译器静态检查机制决定的
Java 在编译阶段就分析每个 catch 参数的类型兼容性。只要某个异常类型是之前已声明 catch 类型的子类或相同类型，编译器就判定该 catch 块“永远无法执行”，报错提示类似：Unreachable catch block for InterruptedException. This exception is already caught by the preceding catch block。这不是运行时行为，而是语法级约束。
并发场景中典型异常的继承关系
常见并发异常都继承自 Exception，例如：
- InterruptedException：直接继承自 Exception
- TimeoutException：继承自 Exception
- ExecutionException：继承自 Exception，常包裹实际任务异常（如 RuntimeException）
- RejectedExecutionException：继承自 RuntimeException → Exception
若把 catch(Exception e) 放在最前，上述所有异常都会被它匹配，后续专门处理 InterruptedException 的逻辑就失效了。
正确写法：从并发特有异常开始，逐级向上收窄
推荐顺序示例：
- 先捕获
InterruptedException（需恢复中断状态或明确响应） - 再捕获
TimeoutException（常用于 Future.get() 超时） - 接着
ExecutionException（提取并处理底层任务异常） - 最后才考虑
Exception，且通常仅用于记录日志后重新抛出，避免掩盖问题
不光是 Exception，父子关系都适用
哪怕只涉及并发包内的异常，只要存在继承关系，就必须遵守子类在前、父类在后：
- ✅ 正确：
catch(TimeoutException e)→catch(ExecutionException e) - ❌ 错误：
catch(ExecutionException e)→catch(TimeoutException e)（编译失败，因 TimeoutException 是 ExecutionException 的子类？注意：实际二者无直接继承关系，但若共属同一父类分支，仍需按具体性排序；关键仍是类型可匹配性）
真正起作用的是“能否被前面的类型实例化”——只要抛出的异常对象 isAssignableFrom 前面 catch 声明的类型，就会被截断。
