Java中native方法抛异常需通过JNI函数显式注册，如ThrowNew；抛出后须立即返回且不可ClearException，否则Java层无法捕获或导致JVM崩溃。
Java中native方法抛出异常，不会自动传递到Java层，必须由C/C++代码显式触发JVM的异常机制，否则Java调用方可能卡死、返回错误值，甚至导致JVM崩溃。
native方法不能直接throw Java异常
在C/C++写的JNI函数里，不能写 throw new RuntimeException("xxx")——这根本不是合法C++语法，更不会被JVM识别。JVM对异常的感知完全依赖于其内部状态标记，而非C++的异常传播机制。
正确做法是：通过JNI接口函数主动“注册”一个待抛出的异常，例如：
- env->ThrowNew(env->FindClass("java/lang/IllegalArgumentException"), "参数非法"); —— 抛出新异常实例
- env->Throw(env->ExceptionOccurred()); —— 重抛已发生的异常（常用于检查并转发上一步JNI调用失败）
异常发生后native函数应立即返回，且不清理已抛异常
JNI规范要求：一旦调用Throw或ThrowNew，该native方法必须尽快返回（通常return，不要继续执行后续逻辑），且不能调用ClearException。因为JVM需要这个异常处于“待处理”状态，才能在返回Java层时自动完成抛出动作。
立即学习“Java免费学习笔记（深入）”；
反例：
- 抛出异常后还去malloc内存、关闭文件句柄、调用其他JNI函数 → 行为未定义，可能crash
- 抛出后立刻调用
env->ExceptionClear()→ 异常被吞掉，Java层收不到，调用方以为操作成功
Java层捕获逻辑不受影响，但需注意“静默失败”风险
只要native端按规范抛出，Java代码可照常用try-catch捕获，和普通Java异常无异：
try {
nativeMethod(); // 内部调用了ThrowNew
} catch (IllegalArgumentException e) {
// 能正常进入这里
}
真正容易出问题的是：native函数没抛异常，却返回了非法值（如null、-1），又没配Java层校验。这时看似“没报错”，实则业务逻辑已错。建议原则：
- 关键native方法应在文档或注释中明确标注“失败时抛XX异常”
- Java层对返回值做基础校验（如指针非null、长度≥0），必要时主动封装成异常
- 调试阶段开启
-Xcheck:jni，JVM会检测异常未处理、重复抛出等违规行为
异常对象可以是自定义类，但必须已加载且可见
使用env->FindClass("com/example/MyException")前，要确保该类已被ClassLoader加载。常见坑：
- 路径用斜杠
/而非点号.（"java/lang/RuntimeException"✓，"java.lang.RuntimeException"✗） - 自定义异常类不在启动类路径或未被任何Java代码触发初始化 → FindClass返回NULL
- 若FindClass失败，应先抛
NoClassDefFoundError，再return，避免后续用空指针
