Result, Option und der ?-Operator: Fehlerbehandlung in Rust

Worum es geht

Result<T, E> ist ein Enum mit Ok(T) und Err(E); Option<T> hat Some(T) und None. Es gibt weder einen Nullpointer noch implizites Entpacken: Um den inneren Wert zu verwenden, muss der Code match einsetzen, if let verwenden, oder eine Methode wie unwrap_or, map, and_then oder ok_or aufrufen. unwrap() und expect("...") extrahieren den Wert und lösen andernfalls einen Panic aus. Das Rust-Buch beschreibt den Fragezeichen-Operator: expr? auf einem Result gibt Err frühzeitig aus der umgebenden Funktion zurück, nachdem der Fehler über den From-Trait auf den deklarierten Fehlertyp der Funktion umgewandelt wurde; auf einer Option gibt er None zurück. Er darf nur in einer Funktion verwendet werden, deren Rückgabetyp kompatibel ist, und main darf Result<(), Box<dyn Error>> zurückgeben, um ihn auf oberster Ebene zu erlauben. Die Dokumentation der Standardbibliothek besagt, dass Result mit #[must_use] annotiert ist, sodass ein Result, das weder gebunden noch verwendet wird, eine Compiler-Warnung auslöst.

Warum es wichtig ist

Exception-basierter Code lässt einen Fehlschlag unsichtbar nach oben wandern; die Signatur einer Python-Funktion sagt nichts darüber aus, was sie auslöst. In Rust steckt die Möglichkeit eines Fehlschlags im Rückgabetyp, der Compiler verweigert es, sie vergessen zu lassen, und derselbe Mechanismus deckt fehlende Werte ab, was die Fehlerklasse des unerwartet zurückgegebenen None beseitigt. Panics existieren, sind aber für Invarianten gedacht, die eine Eingabe nicht verletzen kann, nicht für erwartete Fehlschläge.

So wird es angewendet

• Result von allem zurückgeben, was mit I/O, Parsing oder Nutzerdaten zu tun hat; Option für Lookups zurückgeben, bei denen Fehlen normal ist.
• Pro Crate oder Modul ein Fehler-Enum mit einer Variante pro Ursache definieren, std::error::Error und Display implementieren, und From für die zugrundeliegenden Fehler implementieren, damit ? automatisch umwandelt; Crates wie thiserror generieren diesen Boilerplate-Code.
• In Anwendungscode reicht oft ein undurchsichtiger Fehlertyp mit Kontext (wie ihn das Crate anyhow bietet); Bibliotheken sollten typisierte Fehler bereitstellen, auf die Aufrufende matchen können.
• unwrap und expect für Tests reservieren und für Fälle, in denen die Invariante in der expect-Meldung angegeben ist.
• Kombinatoren für kurze Pipelines verwenden und match, wenn die Zweige Unterschiedliches tun.

Stolpersteine

? innerhalb einer Closure bezieht sich auf die Closure, nicht auf die äussere Funktion. Frühzeitig alles zu Box<dyn Error> umzuwandeln, verliert die Fähigkeit, auf Ursachen zu matchen. let _ = fallible(); unterdrückt die Must-use-Warnung und verwirft den Fehler. Das Mischen von Option und Result in einer Kette braucht ok_or oder transpose.

Welche Fehler ein blosses From verwenden dürfen

Die automatische Umwandlung über From behält genau das, was der innere Fehler sagt, und nichts darüber hinaus. Das reicht für Fehler, die ihren Gegenstand bereits nennen (ein Parse-Fehler mit einer Position, ein Client-Fehler mit der URL). Es reicht nicht für std::io::Error, das weder den Pfad noch die Operation trägt, sodass ? mit From<io::Error> 'No such file or directory' liefert, ohne dass eine Datei genannt wird. Für diese Fälle den Kontext am Aufrufort hinzufügen: eine thiserror-Variante wie #[error("reading {path}")] Io { path: PathBuf, #[source] source: std::io::Error }, befüllt über map_err, oder in Anwendungscode anyhows .with_context(|| format!("reading {}", path.display())). Faustregel: eine From-Implementierung pro Fehlertyp, der sich selbst beschreibt; map_err oder with_context für jeden I/O-Aufruf.