WebAssembly (WASM) for High Performance Apps · Lekcja

Obsługa błędów na granicy WASM

Sprawnie obsługuj wartości Result, Option i paniki z Rusta, gdy przekraczają granicę do JavaScriptu, korzystając z wasm-bindgen.

Obsługa błędów na granicy WASM to bezpłatna lekcja WebAssembly (WASM) for High Performance Apps na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej WebAssembly (WASM) for High Performance Apps, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs WebAssembly (WASM) for High Performance Apps zawiera 4 lekcji w sumie.

Części tej lekcji nie zostały jeszcze przetłumaczone i są wyświetlane po angielsku.

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.

Często zadawane pytania

Czy lekcja „Obsługa błędów na granicy WASM” jest bezpłatna?

Tak — pełny tekst „Obsługa błędów na granicy WASM” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu WebAssembly (WASM) for High Performance Apps, przejdź na CoddyKit PRO. Kurs WebAssembly (WASM) for High Performance Apps zawiera 4 lekcji w sumie.

Co nauczysz się w „Obsługa błędów na granicy WASM”?

Sprawnie obsługuj wartości Result, Option i paniki z Rusta, gdy przekraczają granicę do JavaScriptu, korzystając z wasm-bindgen. Ćwiczysz WebAssembly (WASM) for High Performance Apps z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć WebAssembly (WASM) for High Performance Apps?

Nie wymagamy żadnego doświadczenia. WebAssembly (WASM) for High Performance Apps w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.

Ile czasu zajmuje lekcja „Obsługa błędów na granicy WASM”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji WebAssembly (WASM) for High Performance Apps?

Tak. Każda lekcja WebAssembly (WASM) for High Performance Apps zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

← Powrót do WebAssembly (WASM) for High Performance Apps