WasmRefCell's borrow check should not throw

[mikialex]

Summary

Accroding to rust-lang/rust#58874, wasm's stack unwinding is abort. So, once panic occured, the Ref / RefMut that borrowed from WasmRefCell 's drop cant be executed. After panic happend, we still want (try) wasm instance continue working like before, but the borrow count inside WasmRefCell is "dirty" and not reset by Ref / RefMut's drop, which cause a borrow fail throw to js side and terminate execution.

wasm-bindgen/src/lib.rs

Line 962 in 9554bee

fn borrow_fail() -> ! {

I think maybe log an error to js and reset the borrow count is a better idea than directly throw js error. It can notify borrow error to users and more importantly act as a "panic recovery" .

Additional Details

I'am working on a rendering system in wasm, that every data store in wasm memory, and communicate to js side by handle object generated by wasm-bindgen. I would try very hard to avoid panic happen, but if I missed something I wish the damage is minimized, not crash the all system. I have replaced all refcell to customized not panic implmentation and check all possiible drop.

[alexcrichton]

I agree that there's issues here related to unwinding and destructors, and I think it would be great to fix, but I'm not entirely sure what the fix would look like. If you have a solution in mind could you send a PR?

[ppershing]

Doesn't refcell have similar reasons to keep the dirty state as mutex? Basically, if you panic, you don't have guarantee that the state behind refcell isn't half modified, which in turn means it is unsafe to access it. Rust therefore poisons the value