[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: Dec 06 2025 at 06:05 UTC