Catch Rapier panics at FFI boundary to prevent crash

[hexadexxa]

Rapier internal assertions can panic during the physics step. Since the
JNI functions use extern "system", this unwinds across the FFI boundary
and aborts the JVM.

Wraps pipeline.step() and tick() in catch_unwind so panics are
caught and the tick is skipped instead of crashing.

[CLAassistant]

All committers have signed the CLA.

[hexadexxa]

Should also fix issue #431 if it's the same issue

[Random-Scientist]

this is a really bad idea. the rust panics are panics for a reason; they indicate a fatal error in the physics engine (there is no mechanism for handling recoverable errors at present), ignoring these fatal errors will just invite more UB or breakages in later calls or physics steps, making everything harder to debug.

[ryanhcode]

i think it still propagates to a server crash, just through a jvm exception

[Random-Scientist]

i think it still propagates to a server crash, just through a jvm exception

At present it simply seems to ignore panics altogether (hence my comments). Clearing the physics state and raising a JVM exception with a rust backtrace would be nice but the present version of the pr just makes debugging native crashes harder.

[ryanhcode]

yeah, ignoring the panics is an absolute no-go. I'd be happy if we raised a JVM exception with the details from the panic and unrecoverably crashed the server

[hexadexxa]

I see, I'll try doing that later

[hexadexxa]

Updated. Now catches the panic and throws a RuntimeException with the panic message via env.throw_new, so the server crashes with a proper crash report