异常变量应统一命名为e或带类型前缀的简短名称（如ioE），保持语义清晰、避免歧义，多catch及multi-catch中均用e，显式加final更规范，禁用冗余或误导性命名。
多 catch 块里的异常变量命名，核心不是“起什么名字”，而是**保持语义清晰、避免歧义、符合语言约束**。Java 对异常变量本身有隐式 final 限制，命名需服务于可读性与维护性，而非自由发挥。
异常变量名应统一、简短且具类型提示
推荐统一使用 e 或带前缀的 ioE、sqlE 等，而非追求“见名知意”的长名（如 fileNotFoundExceptionInstance）。原因在于：
- catch 块作用域极小，上下文明确，
e已足够传达“当前捕获的异常对象”这一含义 - 多个并列 catch 中若分别用
e1、e2，反而增加认知负担 - IDE 和日志框架普遍适配
e作为默认参数名，利于工具链协同
多异常合并时仍用单一名字，不因类型变而改名
使用 multi-catch（如 catch (IOException | SQLException e)）时，变量名保持为 e 即可。不要写成 ioOrSqlE 或试图区分类型：
- 编译器已确保
e的静态类型是各异常的最小公共父类（通常是Exception），运行时类型由实际抛出决定 - 名字变化无法增强类型安全，反而破坏一致性；需要区分处理时，应靠
instanceof或e.getClass()，而非变量名 - 显式加
final更规范：catch (IOException | SQLException final e)
避免误导性命名或冗余修饰
以下命名方式应规避：
立即学习“Java免费学习笔记（深入）”；
- exception —— 冗余，类型声明已说明这是异常
-
ex —— 缩写不必要，
e更简洁通用 - myException、tempE —— 加入主观修饰词，无实际信息量
- e1、e2 在同一 try 中多个 catch 里 —— 人为制造序号依赖，违背异常处理的独立性原则
与项目整体风格保持一致
若团队约定所有异常变量用 cause（强调因果）、或统一加后缀如 eIo、eDb，只要全项目统一且不违反 final 约束，就可接受。关键点是：
- 不混用：同一个 catch 块内不出现
e和exc - 不隐藏意图：不用
data、result这类与异常无关的名称 - 配合日志输出：若常写
log.error("xxx", e)，则e是最自然选择
