[rustjava-jvm-exception-throws-instead-of-unwrap] fix(jvm): 일으키려던 예외를 못 만들면 «보고»한다 — 죽지 않는다

[Jun025]

채택 제안 2026-09-18-named-exception-classes-are-loadable#p1 —
"When the runtime cannot build the exception it wants to raise, it crashes the process; it should report the failure the Java way instead."

급소 — 실패가 «이미» JavaError 다

Jvm::exception 은 846 호출부가 끝나는 자리인데 이렇게 돌았다:

let message_str = JavaLangString::from_rust_string(self, message).await.unwrap();
let instance = self.new_class(r#type, "(Ljava/lang/String;)V", (message_str,)).await.unwrap();

둘 다 jvm::Result<T> = Result<T, JavaError> 를 돌려준다 ⇒ ★그 실패는 그 자체가 자바 예외다.
unwrap 이 그것을 버리고 프로세스를 죽였다. ★실측 패닉 문면이 «버려진 보고»를 그대로 싣고 있다:

panicked at jvm/src/jvm.rs:948:94:
called `Result::unwrap()` on an `Err` value: JavaException(ClassInstance(java/lang/NoClassDefFoundError))

load_class 는 이미 올바른 NoClassDefFoundError 를 만들어 건넸다. ⇒ 그대로 돌려준다.

도달성 — 「이론상」과 「실측」을 섞지 않는다

축	실측
이 트리 자기 호출부	★0 — named 43 전건 loadable(PR #72 검사기) 그리고 43 전건이 <init>(Ljava/lang/String;)V 자기 proto 보유(이 회차 실측 · 누락 0 · 조상 의존 0)
공개 API	★도달한다 — pub async fn exception 이고 wie 가 이 크레이트를 싣는다. 로더가 못 주는 이름 ⇒ 호스트 프로세스 사망

축 (★제품 함수 · 픽스처 사본 아님)

jvm/tests/test_exception_construction.rs

jvm/src/jvm.rs 형상	결과
전(.unwrap() 둘)	★FAILED — 위 패닉
후	★ok (1 passed)

★jvm.rs 를 되돌리면 red 가 된다.

호출부 파급 0 — 「조용히 통과하는 경로」를 «구조로» 없앴다

.exception( 846 → 846(편집 0) · JavaError:: 527자리 편집 0.
★대안이던 「JavaError 에 variant 추가」를 버린 이유: let …else/if let 460자리가 조용히 else 로 새고,
jvm.rs:1073 의 반증불가 let(변형이 하나라서 컴파일되는 자리)이 깨진다. 이 형상은 그 함정을 애초에 만들지 않는다.

★대가 (숨기지 않는다)

실패 시 호출자는 요청한 것과 다른 예외 클래스를 받는다 ⇒ 잡은 예외를 클래스로 분기하는 제품 12자리
(print_stream·print_writer·filter_output_stream·formatter 의 IOException · integer·long 의 NumberFormatException)는
그 경우 못 잡고 전파한다. 죽는 것보다 낫지만 무해한 변경이 아니다.

자기 diff 밖 파급 둘 (둘 다 선택이 아니었다)

⑴★검사기 문면 3자리가 «거짓»이 됐다 — 「unwraps … aborts the process」·「DELIBERATELY NOT DONE HERE: turning the .unwrap() into a thrown exception」·실패 메시지 「panics instead of throwing」.
⇒ 문면만 고쳤다(술어 무접촉). 잠금의 «이유»가 「죽는다」 → ★**「틀린 예외가 온다」**(IOException 을 물었는데 NoClassDefFoundError 가 와서 catch 가 안 걸린다)로 바뀌고, 더 조용하므로 잠금 가치는 커졌다.
★그 축 양방향 재검증: 등재 1줄 제거 → rc=1 · 원복 → rc=0.

⑵★★형제 회차의 «비리터럴 0» 이 «1» 이 된다 — 이 테스트는 못 싣는 이름을 불러야 하고, 리터럴로 쓰면 loadable 검사기가 실제로 red 였다(실측 · :13 지목) ⇒ 이름을 변수로 든다.
★그 회차가 «0 을 관문으로 올리지 않은» 판단이 하루 만에 값을 했다 — 걸었으면 이 테스트가 막혔다.
※그 술어가 주석 안의 토큰도 센다는 것도 이때 드러났다(주석 때문에 2로 읽힘 → 문구 교체).

안 고친 것

• ★퇴화 경우는 불변이고 «패닉이 아니라 무한 재귀»다: NoClassDefFoundError 자신이 안 실리면 load_class → exception → new_class → load_class 가 돈다. ★옛 unwrap 도 못 막았다(안쪽 new_class 가 돌아오지 않아 unwrap 에 닿지 않는다). ★호출그래프에서 읽은 것이고 실측이 아니다 — 커스텀 로더 하네스가 필요해 범위 밖(후속 카드).
• from_rust_string 쪽도 같은 방식으로 고쳤지만 ★재현 경로를 못 찾았다 — 주장하지 않는다.

DoD (9명령 전건 rc=0)

fmt 0 · clippy stable 0 · clippy +beta 0 · clippy wasm32 0 · cargo test --all 585 passed / 0 failed / 1 ignored(내 테스트 ok) · check-worklog-json 0 · check-dod-ci-parity 0 · check-named-exception-classes-are-loadable 0(846/43/268) · check-merge-dropped-symbols 0