java中不能在catch块里动态转换异常类型，只能通过新建异常实例并重抛来实现包装、映射或重抛；需保留异常链、避免吞异常、谨慎处理受检异常，并防止finally覆盖异常。
Java中不能在catch块里“动态转换”异常类型——这不是语言支持的操作。所谓“转换”，实际是指捕获一种异常后，主动抛出另一种异常（即异常包装或重抛），目的是统一错误语义、隐藏底层实现细节，或适配上层接口约定。
为什么不能真正“转换”异常类型
catch语句的类型匹配发生在编译期和JVM异常分发阶段，由字节码指令athrow和异常表（exception table）决定。一旦异常对象被某个catch块捕获，它的运行时类型就固定了；你无法修改其class对象或强制转型为另一个不相关的类型。所谓“转换”，本质是新建一个异常实例并重新throw。
常用技术路径：包装、重抛与自定义映射
实践中主要有三种安全且标准的做法：
-
包装异常（Exception Chaining）：用新异常包裹原始异常，保留原始堆栈。推荐使用带cause参数的构造器，例如
new BusinessException("文件处理失败", e)。调用e.getCause()可追溯根源。 -
直接重抛同类型或子类：若原始异常已符合业务语义（如
IllegalArgumentException），可不做包装，仅做日志或补充信息后重新throw。注意不要丢失原始堆栈：throw e;而非throw new RuntimeException(e.getMessage()); -
按规则映射为特定业务异常：针对不同底层异常类型，映射为预定义的业务异常类。例如将
SQLException统一转为DataAccessException，将IOException转为StorageException。需配合if-else或switch（Java 14+）判断e.getClass()。
关键细节与避坑点
操作时必须注意以下几点：
- 避免丢弃原始异常：空参构造新异常会切断异常链，调试时无法定位真实原因。
- 不要在catch中吞掉异常又不记录：即使要转成业务异常，也应在log中保留
e.printStackTrace()或使用日志框架记录warn/error级别日志。 - 受检异常转非受检需谨慎：若原方法声明不抛出受检异常，而你在catch中throw新的受检异常，会导致编译失败；此时应转为RuntimeException及其子类。
- finally中不要throw异常：否则可能覆盖try/catch中已准备好的业务异常，导致真实错误被掩盖。
一个典型示例
读取配置文件时，把底层IO异常转化为统一的配置异常：
try {
return Files.readString(Paths.get("config.json"));
} catch (NoSuchFileException e) {
logger.warn("配置文件不存在", e);
throw new ConfigLoadException("配置文件缺失", e);
} catch (IOException e) {
logger.error("读取配置文件失败", e);
throw new ConfigLoadException("I/O错误导致配置加载失败", e);
}Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
