反射获取异常处理技巧：受检与运行时异常分析

Java反射中的Method.getExceptionTypes()方法仅能获取方法显式声明的受检异常（即继承自Exception但非RuntimeException的子类），完全不包含运行时异常（如NullPointerException、IllegalArgumentException等）、Error以及通过Lombok @SneakyThrows等手段绕过throws声明的异常——这意味着它揭示的是编译期契约而非实际运行行为，精准理解这一限制，是安全进行异常处理、动态调用和API契约分析的关键前提。

Java 反射中获取方法声明的异常类型，是理解其契约行为的关键一步。通过 Method.getExceptionTypes()，你能准确知道该方法在编译期承诺抛出哪些受检异常——而运行时异常（RuntimeException 及其子类）和 Error 不会出现在这个列表里，哪怕方法体内实际抛出了它们。

getExceptionTypes() 只返回受检异常

这个方法返回的是 Class[]，但内容仅限于明确在 throws 子句中声明的、继承自 Exception 但不继承自 RuntimeException 的类型。例如：

• void readFile() throws IOException, SQLException → 返回 {IOException.class, SQLException.class}
• void riskyOp() throws RuntimeException → 不会 出现在结果中（因为 RuntimeException 是非受检的）
• void unsafeCast() throws ClassCastException → 同样不会出现（它是 RuntimeException 的子类）

如何区分受检与非受检异常类型

拿到异常类数组后，可用以下逻辑判断每个类是否属于受检异常：

• 若 clazz == RuntimeException.class || clazz == Error.class → 非受检
• 若 RuntimeException.class.isAssignableFrom(clazz) → 非受检（含所有运行时异常子类）
• 若 Error.class.isAssignableFrom(clazz) → 非受检
• 其余继承自 Exception 的类 → 属于受检异常

反射无法捕获“偷偷抛出”的受检异常

像 @SneakyThrows 这类编译期字节码操作，会让受检异常绕过 throws 声明直接抛出。此时 getExceptionTypes() 返回空数组，但运行时仍可能抛出 IOException 等原始类型。这意味着：

• 反射结果反映的是源码层面的显式契约，不是运行时真实行为
• 调用方若依赖反射做异常检查（如框架自动包装），需额外考虑 Lombok 或手动 throw (RuntimeException) new XxxException() 场景
• IDE 和 javac 不会报错，但静态分析工具或强契约校验逻辑可能失效

实用建议：安全调用反射获取的方法

当你通过反射调用一个未知方法，并希望统一处理异常时，推荐按如下顺序捕获：

• 先 catch (InvocationTargetException e)，再用 e.getTargetException() 拿到原始异常
• 对原始异常做类型判断：是 RuntimeException 或 Error 就重新抛出；是其他 Exception 就按业务逻辑处理或包装
• 不要只依赖 getExceptionTypes() 来决定是否 try-catch —— 它漏掉了所有非受检路径

以上就是《反射获取异常处理技巧：受检与运行时异常分析》的详细内容，更多关于的资料请关注golang学习网公众号！