model exceptions as panics

[dherman]

Modeling JS exceptions as Result was a mistake. It's not possible to re-enter the engine when it's in a throwing state, so it's unsafe for Rust to continue running after V8 triggers an exception. Instead, we should model exceptions as panics, and offer a callback-based API for catching exceptions. This will have the nice side effect of making almost all Neon APIs vastly lighter-weight.

Also, we should use catch_unwind to catch Rust internal panics and prevent them from crashing V8.

[bnoordhuis]

You're probably well aware but you can clear a pending exception with v8::TryCatch::Reset(). If you consistently guard all entry points into the VM, you can keep on using the result-or-failure idiom. You will have to deal with empty handle return values anyway (i.e., without an associated exception) so result-or-failure is presumably still going to be necessary.

The, ah, exception to the rule is the termination exception introduced by v8::Isolate::TerminateExecution(). It can be cancelled again with a call to v8::Isolate::CancelTerminateExecution() (and detected with v8::TryCatch::HasTerminated() and v8::TryCatch::Continue()) but panicking might be more appropriate.

[DemiMarie]

I don't think panicking should be used by the library during normal operation. Rust programs can be compiled to abort on panic, and panicking is not optimized at all.

Better to use Result. When TerminateExecution is called, all calls into the API should fail. The cost of a single well-predicted branch is negligible.

Rust-side panics should result in calls to TerminateExecution if they escape to Neon.

[dherman]

The design will need to be sketched out in the error safety RFC.

[dherman]

Closing this since it should be part of the RFC design discussion.