WebAssembly (WASM) for High Performance Apps · Lektion

Fehlerbehandlung über die WASM-Grenze hinweg

Behandeln Sie Rust Results, Options und Panics sauber, wenn sie mithilfe von wasm-bindgen nach JavaScript übertragen werden.

Fehlerbehandlung über die WASM-Grenze hinweg ist eine kostenlose WebAssembly (WASM) for High Performance Apps-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des WebAssembly (WASM) for High Performance Apps-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der WebAssembly (WASM) for High Performance Apps-Kurs umfasst insgesamt 4 Lektionen.

Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.

Errors Need a Bridge

Rust uses Result and Option for errors; JavaScript uses exceptions and null/undefined.

wasm-bindgen bridges these two worlds so failures surface naturally on each side.

Returning Result to JS

A Rust function returning Result<T, JsValue> becomes a JS function that either returns the value or throws.

use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn parse(input: &str) -> Result<i32, JsValue> {
    input.parse::<i32>()
        .map_err(|e| JsValue::from_str(&e.to_string()))
}

Catching It in JavaScript

On the JS side, an Err arrives as a thrown exception, so wrap calls in try/catch.

try {
  const n = parse('abc');
} catch (e) {
  console.error('Parse failed:', e);
}

Mapping Custom Errors

Convert your own error types into a JsValue so JS gets a useful message. The ? operator plus map_err keeps this clean.

#[wasm_bindgen]
pub fn divide(a: i32, b: i32) -> Result<i32, JsValue> {
    if b == 0 {
        return Err(JsValue::from_str('division by zero'));
    }
    Ok(a / b)
}

Returning Option

Rust's Option<T> maps to a value or undefined in JS, perfect for nullable results.

#[wasm_bindgen]
pub fn first_char(s: &str) -> Option<char> {
    s.chars().next()
}

What Happens on Panic

A Rust panic in WASM aborts the module and is hard to debug, by default you get an unhelpful 'unreachable' error.

Panics should be rare; prefer Result for expected failures.

Better Panic Messages

The console_error_panic_hook crate forwards panic messages to the browser console, making debugging far easier.

#[wasm_bindgen(start)]
pub fn main() {
    console_error_panic_hook::set_once();
}

Result vs Panic

Choose deliberately:

Result, expected, recoverable errors (bad input, not found)
Panic, programmer bugs and invariants that should never break

Never use panics for normal control flow across the boundary.

Using a Custom Error Type

For richer errors, define a struct exported to JS, so JS can read fields instead of just a string.

#[wasm_bindgen]
pub struct AppError { pub code: i32 }

#[wasm_bindgen]
impl AppError {
    #[wasm_bindgen(getter)]
    pub fn code(&self) -> i32 { self.code }
}

Propagating with ?

Inside a function returning Result<_, JsValue>, the ? operator propagates errors cleanly when types convert.

#[wasm_bindgen]
pub fn run(input: &str) -> Result<i32, JsValue> {
    let n: i32 = input.parse().map_err(|_| JsValue::from_str('bad'))?;
    Ok(n * 2)
}

Best Practices Summary

For robust error handling:

Return Result<T, JsValue> so errors become JS exceptions
Return Option for nullable values
Install console_error_panic_hook for debuggable panics
Reserve panics for true bugs, use Result for expected failures

Quick Check

How does a Rust function returning Result<T, JsValue> behave when it returns Err and is called from JavaScript?

Recap

You now handle errors cleanly across the boundary:

Result becomes a JS throw; Option becomes value-or-undefined
Map custom errors into JsValue
Use console_error_panic_hook to debug panics
Prefer Result over panic for expected failures

Clear error semantics make Rust+WASM libraries pleasant and safe to consume from JS.

Häufig gestellte Fragen

Ist die Lektion „Fehlerbehandlung über die WASM-Grenze hinweg“ kostenlos?

Ja — der vollständige Text von „Fehlerbehandlung über die WASM-Grenze hinweg“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des WebAssembly (WASM) for High Performance Apps-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der WebAssembly (WASM) for High Performance Apps-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Fehlerbehandlung über die WASM-Grenze hinweg“?

Behandeln Sie Rust Results, Options und Panics sauber, wenn sie mithilfe von wasm-bindgen nach JavaScript übertragen werden. Du übst WebAssembly (WASM) for High Performance Apps mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um WebAssembly (WASM) for High Performance Apps zu starten?

Keine Vorkenntnisse erforderlich. WebAssembly (WASM) for High Performance Apps auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.

Wie lange dauert die Lektion „Fehlerbehandlung über die WASM-Grenze hinweg“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser WebAssembly (WASM) for High Performance Apps-Lektion Code schreiben und ausführen?

Ja. Jede WebAssembly (WASM) for High Performance Apps-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

Rust für WebAssembly einrichten
Rust-Funktionen für WASM schreiben
Effiziente JS-Interoperabilität mit `wasm-bindgen`
Fehlerbehandlung über die WASM-Grenze hinweg

← Zurück zu WebAssembly (WASM) for High Performance Apps