Expose wasmtime_runtime::InstantiationError
as a stable wasmtime API
#3928
Labels
wasmtime:api
Related to the API of the `wasmtime` crate itself
wasmtime
Issues about wasmtime that don't fall into another label
Feature
Presently, the
instantiate
family of functions (Linker::instantiate
,InstancePre::instantiate
, their _async cousins etc) error with ananyhow::Error
. To inspect those errors, we can try downcasting towasmtime_runtime::InstantiationError
.Benefit
Users who need to inspect those errors need to keep their deps of wasmtime and wasmtime_runtime in sync. wasmtime_runtime's API is not designed for stable use. Stabilizing this error API gets rid of a possible runtime dep for users.
The
InstantiationError::Limit
variant is used when a wasmtime pooling allocator is out of instances. This is the only way that wasmtime crate users can observe this condition. There should be a stable way to observe this.The
InstantiationError::Trap
variant contains awasmtime_runtime::Trap
, which is different from awasmtime::Trap
in ways that aren't useful to wasmtime users, and can be confusing.Implementation
I think it makes sense for the instantiate family of functions to still error with an
anyhow::Error
, but wasmtime should export types to try downcasting that error to.Wasmtime should not re-export
wasmtime_runtime::InstantiationError
because it exposes the wrong sort ofTrap
. Instead it should map the variants to types which are in the public API.wasmtime_runtime::LinkError
for downcasting to that variant, since this is just a string wrapper.wasmtime::Trap
.PoolingAllocatorLimit
andimpl Error
on it, and map theInstantiationError::Limit
variant to that type.Alternatives
There are probably other good ideas I haven't thought of here! I am very open to suggestions.
The text was updated successfully, but these errors were encountered: