What causes "Exception handling is not yet supported in js" in wasmerio/wasmer?

Use wasm modules compiled without exception handling (disable wasm EH in the toolchain, e.g. -fwasm-exceptions off / legacynot-eh) when targeting the js backend

wasmerio/wasmer · error

Exception handling is not yet supported in js

Error message

Exception handling is not yet supported in js

What it means

The JavaScript backend's Exception entity (wasm exception handling) is a stub: Exception::new is declared but calls `unimplemented!("Exception handling is not yet supported in js")`, so any attempt to create a JS-backend exception panics. The JS/Wasm heap backend never implemented the exception tag/payload machinery.

Source

Thrown at lib/api/src/backend/js/entities/exception.rs:23

    AsStoreMut, AsStoreRef, Tag, Value,
    js::vm::{VMException, VMExceptionRef},
};
use std::any::Any;
use wasmer_types::{TagType, Type};

#[derive(Debug, Clone, PartialEq, Eq)]
/// A WebAssembly `tag` in the `v8` runtime.
pub(crate) struct Exception {
    pub(crate) handle: VMException,
}

unsafe impl Send for Exception {}
unsafe impl Sync for Exception {}

impl Exception {
    /// Create a new [`Exception`].
    pub fn new(store: &mut impl AsStoreMut, tag: Tag, payload: &[Value]) -> Self {
        unimplemented!("Exception handling is not yet supported in js");
    }
}

View on GitHub (pinned to 8c4b9ee9d3)

Solutions

Use wasm modules compiled without exception handling (disable wasm EH in the toolchain, e.g. -fwasm-exceptions off / legacynot-eh) when targeting the js backend
Run such workloads on the native (sys) backend where EH is implemented
Upgrade wasmer and check whether js-backend exception support landed
Guard embedder code: detect EH-using modules up front and reject them on the js backend with a clear error instead of a panic

Example fix

// embedder-side guard before instantiating
if module_exports_or_features_use_eh(&module) && backend_is_js() {
    return Err("exception handling unsupported on js backend");
}

Defensive patterns

Strategy: validation

Validate before calling

// before instantiating on the js backend
if uses_wasm_exceptions(&module_bytes) {
    return Err("module uses wasm exception handling; unsupported on js backend");
}
function uses_wasm_exceptions(bytes) { return new WebAssembly.Module(bytes) && importsUseTags(bytes); }

Prevention

Compile modules with wasm exception handling disabled for js targets
Route EH-using modules to the native sys backend
Check module imports for tag imports before instantiation
Keep wasmer-js updated for EH feature status

When it happens

Trigger: Running wasmer with the js backend (wasm32-unknown/emscripten target under wasm) and executing a wasm module that uses wasm exception handling (throw / exception.new via a Tag) — the store tries to construct backend::Exception and hits the unimplemented constructor.

Common situations: Deploying wasmer compiled to JavaScript/Web in browsers or Node; modules using the exception-handling proposal or Emscripten EH (setjmp/longjmp via wasm EH); feature-parity gaps between native (sys) and js backends.

Related errors

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