[crates/api/src/error.rs:25] &e = Trap {
message: "test 123",
wasm_trace: [
...
[crates/api/src/error.rs:26] e.is::<Trap>() = false
Anyone know of ways an anyhow::Error doesn't want to be what it seems to be?
@Dan Gohman there's a weird difference in the downcasting methods
Error::downcast_ref
is different from <Error as Any>::downcast_ref
the former recursively checks the whole chain while the latter only checks the top-most error
it looks like Error::is
isn't defined, it's <Error as Any>::is
, which I think means it's not checking the whole chain
so it may be that a Trap
has some extra context attached to it
so the underlying trap is still there but the top-level type isn't Trap
e.downcast_ref::<Trap>().is_some()
in theory should be true
er I could also be totally wrong, just misread the docs
Error::is
is indeed a thing...
hm got some code to poke around in?
@Alex Crichton I have a branch here: https://github.com/sunfishcode/wasmtime/tree/sunfishcode/exit-unwind
it's wip, and not complete, but cargo test test_trap_return
fails and I'm trying to determine why
See the dbg's in crates/api/src/error.rs
oh Trap::User
isn't an anyhow::Error
it's a dyn std::error::Error
yeah, so we downcast
the std::error::Error
to get the Trap
out, and then stick it in a anyhow::Error
and that Error
no longer claims to be is::<Trap>()
poking around, where's this error constructed?
oh
I believe it ultimately comes from catch_traps
this is b/c the return type of closuers changed
from Trap
to anyhow::Error
so the Trap::User(..)
now is always anyhow::Error
under the hood
so to downcast that you'd have to downcast to anyhow::Error
first
for a patch like this you'd probably want to replace Trap::User
's payload with anyhow::Error
not really much reason in trying to be so general
with std::error::Error
Ok, makes sense
Last updated: Nov 22 2024 at 16:03 UTC