You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, it translates to a RuntimeError being raised in the JS host, that stringifies to "RuntimeError: unreachable executed". This is not helpful. Even if you are using a browser's debugger, at best you'll get the name of the function that panicked and the line in the WAT. The WAT isn't very readable, at least to me.
This will shadow the panic! macro in the standard library and allow you to use panic! freely throughout your crate. In release mode everything will optimize away and no strings will be emitted, but in debug mode you'll see why something is panicking (including filename/line number) on the console. By shadowing panic! you're able to also reuse standard macros like assert! and they'll use this implementation of panic.
The downside of this approach is that it doesn't handle panics originating in foreign libraries, for example unwrap() which panics inside the standard library. That'll definitely require a more intrusive and heavyweight solution.
Right now, it translates to a
RuntimeError
being raised in the JS host, that stringifies to"RuntimeError: unreachable executed"
. This is not helpful. Even if you are using a browser's debugger, at best you'll get the name of the function that panicked and the line in the WAT. The WAT isn't very readable, at least to me.When we have something like https://github.com/rust-lang-nursery/rust-wasm/issues/16#issuecomment-363956170, the default panic handler could use this functionality to essentially do a
console.error
log.The text was updated successfully, but these errors were encountered: