What causes "not yet implemented" in wasmerio/wasmer?

Avoid enabling wasm exception handling on builds where lib/vm/src/libcalls/eh/dwarf/eh.rs still panics in this branch

not yet implemented

Error message

not yet implemented

What it means

find_eh_action in wasmer's DWARF-based exception handling implements the two-level call-site/landing-pad table walk only for the case where the instruction pointer IS found in the LSDA table; the `else` branch (Ip not found in the table structure being scanned) is `todo!()`, panicking instead of returning an EHAction. It represents an incomplete personality-routine-style scan for wasm exception handling.

Source

Thrown at lib/vm/src/libcalls/eh/dwarf/eh.rs:290

                                        lpad,
                                        tags: catches,
                                    }
                                });
                            }

                            action_record = action_record_reader
                                .ptr
                                .wrapping_add(next_action_record as usize);
                        }
                    }
                }
            }
        }

        // Ip is not present in the table. This indicates a nounwind call.
        Ok(EHAction::Terminate)
    } else {
        todo!()
    }
}

#[inline]
fn round_up(unrounded: usize, align: usize) -> Result<usize, ()> {
    if align.is_power_of_two() {
        Ok(unrounded.next_multiple_of(align))
    } else {
        Err(())
    }
}

/// Reads an offset (`usize`) from `reader` whose encoding is described by `encoding`.
///
/// `encoding` must be a [DWARF Exception Header Encoding as described by the LSB spec][LSB-dwarf-ext].
/// In addition the upper ("application") part must be zero.
///
/// # Errors

View on GitHub (pinned to 8c4b9ee9d3)

Solutions

Avoid enabling wasm exception handling on builds where lib/vm/src/libcalls/eh/dwarf/eh.rs still panics in this branch
Return EHAction::Terminate for the nounwind/unmatched case once semantics are confirmed, or implement the missing table-walk branch
Track/upgrade to a wasmer release completing the dwarf EH lookup
For library users: compile modules so throwing calls are explicitly covered by EH regions, avoiding the uncovered path

Example fix

// before
} else {
    todo!()
}
// after
} else {
    // Ip not found: call cannot unwind through this frame
    Ok(EHAction::Terminate)
}

Defensive patterns

Strategy: try-catch

Validate before calling

// reject EH-using modules on builds with incomplete dwarf EH
fn module_uses_exceptions(module: &Module) -> bool { module.imports().tags().count() > 0 }

Type guard

fn eh_supported(build: &str) -> bool { /* check version/feature */ build.contains("eh-complete") }

Try / catch

match run_result {
    Err(e) if is_todo_panic(&e) => disable_eh_or_fallback_to_sys_backend(),
    other => other,
}

Prevention

Compile wasm without exception handling when targeting wasmer builds with stub dwarf EH
Run EH workloads on the native sys backend until the dwarf path is complete
Keep EH proposal flags off by default in browser/embedder configs
Track upstream wasm exception-handling support before enabling it

When it happens

Trigger: A wasm module using exception handling (tag/new exn/throw, legacy EH or exnref) whose unwinding path reaches find_eh_action with an Ip that falls in the branch not covered — i.e. unwinding a frame where the DWARF/LSDA lookup takes the else path.

Common situations: Running wasm with Wasm exception-handling proposals under the VM with the dwarf EH runtime; modules mixing nothrow (nounwind) calls with EH regions on the not-yet-implemented code path; enabling EH flags on a wasmer build where dwarf/eh is partial.

Related errors

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