java中catch块的异常变量默认隐式final，编译器强制禁止对其重新赋值，以确保异常对象不可变、调用栈完整、错误信息可追溯，所有catch形式均等价于显式声明final。
Java 中 catch 块里的异常变量（比如 catch (IOException e) 中的 e）默认就是 隐式 final 的，这不是可选风格，而是编译器强制要求。
防止异常对象被意外替换
一旦异常对象被抛出并进入 catch 块，e 就被绑定到那个具体的异常实例。如果允许重新赋值，比如写 e = null 或 e = new RuntimeException()，就可能掩盖原始错误信息，破坏调用栈的完整性——而这是调试和日志分析的关键依据。
- 编译器会直接报错：
cannot assign a value to final variable e - 哪怕只是临时“清空”引用（如
e = null），也不被允许 - 这个限制对所有 catch 形式都生效：单 catch、多 catch、multi-catch（
catch (IOException | SQLException e)）
语义上等价于显式声明 final
写 catch (Exception e) 实际上等价于 catch (final Exception e)。JVM 要求该参数在作用域内不可重绑定，确保它始终指向最初捕获的那个异常对象。
- 你可以安全调用
e.getMessage()、e.printStackTrace()、e.getCause() - 但不能改变
e所指向的对象引用 - 如需包装或转换异常，应新建一个异常并
throw，而不是篡改e
避免逻辑混淆和资源误判
如果允许修改 e，开发者可能误以为“重赋值后继续处理的是新异常”，但实际上 finally 或外层代码看到的仍是原始异常；更严重的是，某些框架（如日志系统、监控工具）依赖异常对象的原始状态做判断，篡改 e 会导致行为不可预测。
- 例如 Hadoop 中因缺少
common-logging导致static Log初始化失败，抛出的是NoClassDefFoundError（属于Error，非Exception子类），此时若试图用catch (Exception e)捕获就会失效——这和e是否 final 无关，但凸显了异常类型体系的严谨性，而final e正是这种严谨性的底层保障之一
设计初衷是保证异常处理的可信与可追溯
Java 异常机制的核心目标之一是让错误信息真实、完整、可追溯。e 不可变，等于锁定了错误源头；后续所有操作（日志、包装、上报）都基于这个确定的起点展开，不会因中间变量被覆盖而丢失上下文。
- 不支持赋值，不是为了“限制自由”，而是为了守住错误诊断的第一道防线
- 需要变更行为时，应创建新异常对象，保留原异常作为 cause，形成链式结构
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
