What causes "new is only implemented for the sys backend" in wasmerio/wasmer?

Enable/use only the sys backend when working with Wasm exceptions

new is only implemented for the sys backend

Error message

new is only implemented for the sys backend

What it means

Exception::new creates a WebAssembly exception (exception-handling proposal), but the enum wrapper only implements construction for the sys backend; any other configured backend hits the catch-all arm and panics with unimplemented!().

Source

Thrown at lib/api/src/entities/exception/inner.rs:36

}

impl BackendException {
    /// Create a new exception with the given tag type and payload.
    #[inline]
    #[allow(irrefutable_let_patterns)]
    pub fn new(store: &mut impl AsStoreMut, tag: &Tag, payload: &[Value]) -> Self {
        match &store.as_store_mut().inner.store {
            #[cfg(feature = "sys")]
            crate::BackendStore::Sys(_) => {
                let BackendTag::Sys(tag) = &tag.0 else {
                    panic!("cannot create Exception with Tag from another backend");
                };

                Self::Sys(crate::backend::sys::exception::Exception::new(
                    store, tag, payload,
                ))
            }
            _ => unimplemented!("new is only implemented for the sys backend"),
        }
    }

    /// Checks whether this `Exception` can be used with the given store.
    #[inline]
    pub fn is_from_store(&self, store: &impl AsStoreRef) -> bool {
        match self {
            #[cfg(feature = "sys")]
            Self::Sys(s) => s.is_from_store(store),
            _ => unimplemented!("is_from_store is only implemented for the sys backend"),
        }
    }

    /// Gets the exception tag.
    #[inline]
    pub fn tag(&self, store: &impl AsStoreRef) -> Tag {
        match self {
            #[cfg(feature = "sys")]

View on GitHub (pinned to 8c4b9ee9d3)

Solutions

Enable/use only the sys backend when working with Wasm exceptions
Feature-gate exception usage: check the active backend before creating exceptions
Communicate errors via ordinary imports/returns instead of wasm exceptions on non-sys backends
Contribute Exception::new implementations for other backends

Example fix

// before
let exn = Exception::new(&mut store, &tag, payload);
// after
let exn = match store.engine().backend() {
    Backend::Sys => Exception::new(&mut store, &tag, payload),
    _ => return Err("exceptions require the sys backend".into()),
};

Defensive patterns

Strategy: validation

Validate before calling

fn exceptions_supported(store: &impl AsStoreRef) -> bool {
    matches!(store.as_store_ref().engine().backend(), Backend::Sys)
}

Type guard

fn is_sys_exception(ex: &ExceptionInner) -> bool {
    matches!(ex, ExceptionInner::Sys(_))
}

Try / catch

let exn = std::panic::catch_unwind(|| Exception::new(&mut store, &tag, payload));
match exn {
    Ok(e) => Ok(e),
    Err(_) => Err(UnsupportedBackendError::Exceptions),
}

Prevention

Enable exceptions only with the sys feature enabled
Assert the backend at startup when using the exception-handling proposal
Add cross-backend CI jobs to catch these early

When it happens

Trigger: Calling Exception::new(store, tag, payload) when the store's backend is anything other than sys (e.g. v8, wasmi, wasm_c_api) while the exception feature is enabled.

Common situations: Apps using the wasm exception-handling proposal that switch engines; test suites running the same code across multiple backend features.

Related errors

AI-assisted analysis of wasmerio/wasmer@8c4b9ee9d3 (2026-09-01). Data as JSON: /api/errors/c197a536d6ba19dd. Report an issue: GitHub.