Die Fehlerbehandlung in Rust basiert auf zwei Enums—Result<T, E> und Option<T>—die eine explizite Behandlung von Erfolg, Fehlschlag und Abwesenheit zur Kompilierzeit erzwingen. Anders als Exceptions, die unsichtbar propagieren, macht der Rust-Ansatz Fehlerpfade in Funktionssignaturen sichtbar und eliminiert ganze Kategorien von Laufzeitüberraschungen. Der ?-Operator, kombiniert mit den Crates thiserror und anyhow, vereinfacht dieses explizite Modell ohne Einbußen bei der Klarheit.

Wann welchen Typ verwenden

Option<T> eignet sich für Werte, die legitimerweise fehlen können (Konfigurationsfelder, Suchergebnisse). Result<T, E> kommt zum Einsatz, wenn Operationen mit aussagekräftigen Fehlerinformationen fehlschlagen können (Datei-I/O, Netzwerkanfragen, Parsing).

Grundlagen von Result und Option

Result<T, E> repräsentiert entweder Erfolg (Ok(T)) oder Fehlschlag (Err(E)). Option<T> repräsentiert entweder einen Wert (Some(T)) oder Abwesenheit (None). Beide sind Summentypen—der Compiler stellt sicher, dass jede Variante behandelt wird.

error_examples.rsrust

// Demonstrates Result and Option basic patterns

fn find_user(id: u64) -> Option<String> {
    // Returns None if user doesn't exist
    if id == 0 {
        None
    } else {
        Some(format!("User-{}", id))
    }
}

fn parse_port(s: &str) -> Result<u16, std::num::ParseIntError> {
    // Returns Err if parsing fails
    s.parse::<u16>()
}

fn main() {
    // Option handling - must address None case
    match find_user(42) {
        Some(name) => println!("Found: {}", name),
        None => println!("User not found"),
    }

    // Result handling - must address Err case
    match parse_port("8080") {
        Ok(port) => println!("Port: {}", port),
        Err(e) => println!("Invalid port: {}", e),
    }
}

Der Compiler weist Code zurück, der diese Rückgabewerte ohne explizite Behandlung ignoriert. Dieses Design fängt Fehler zur Kompilierzeit ab, die in anderen Sprachen als Null-Pointer-Exceptions oder nicht abgefangene Fehler auftreten würden.

Der Fragezeichen-Operator für prägnante Propagierung

Der ?-Operator transformiert umständliche match-Ketten in lesbaren linearen Code. Bei Anwendung auf ein Result erfolgt ein vorzeitiger Return mit dem Fehler, falls vorhanden, oder der Erfolgswert wird entpackt. Gleiches gilt für Option.

file_reader.rsrust

// Using ? for clean error propagation

use std::fs::File;
use std::io::{self, BufRead, BufReader};

fn read_first_line(path: &str) -> Result<String, io::Error> {
    let file = File::open(path)?;  // Returns early if open fails
    let mut reader = BufReader::new(file);
    let mut line = String::new();
    reader.read_line(&mut line)?;  // Returns early if read fails
    Ok(line.trim().to_string())
}

fn get_port_from_config(path: &str) -> Result<u16, Box<dyn std::error::Error>> {
    let content = read_first_line(path)?;
    let port = content.parse::<u16>()?;  // ParseIntError converts via From
    Ok(port)
}

Der ?-Operator erfordert, dass der Fehlertyp über das From-Trait in den Rückgabe-Fehlertyp der Funktion konvertierbar ist. Die Verwendung von Box<dyn std::error::Error> wie oben gezeigt akzeptiert jeden Fehlertyp, der das Standard-Error-Trait implementiert.

Benutzerdefinierte Fehler mit thiserror erstellen

Das thiserror-Crate eliminiert Boilerplate für benutzerdefinierte Fehlertypen. Es leitet Error-, Display- und From-Implementierungen durch ein prozedurales Makro ab.

errors.rsrust

// Custom error types using thiserror 2.0

use thiserror::Error;

#[derive(Error, Debug)]
pub enum ConfigError {
    #[error("configuration file not found at {path}")]
    NotFound { path: String },

    #[error("invalid port number: {0}")]
    InvalidPort(#[from] std::num::ParseIntError),

    #[error("IO error reading config")]
    IoError(#[from] std::io::Error),

    #[error("missing required field: {0}")]
    MissingField(String),
}

fn load_config(path: &str) -> Result<Config, ConfigError> {
    let content = std::fs::read_to_string(path)?;  // IoError auto-converts
    let port: u16 = content
        .lines()
        .find(|l| l.starts_with("port="))
        .ok_or(ConfigError::MissingField("port".into()))?
        .strip_prefix("port=")
        .unwrap()
        .parse()?;  // ParseIntError auto-converts to InvalidPort

    Ok(Config { port })
}

struct Config {
    port: u16,
}

Das #[from]-Attribut generiert automatische Konvertierungen, die eine nahtlose Verwendung von ? mit verschiedenen zugrundeliegenden Fehlertypen ermöglichen. Fehlermeldungen werden durch die #[error(...)]-Formatstrings selbstdokumentierend.

Fehler auf Anwendungsebene mit anyhow

Während thiserror sich für Bibliothekscode mit spezifischen Fehlertypen eignet, zielt anyhow auf Anwendungen ab, bei denen Fehlerkontext wichtiger ist als Typgranularität. Das Context-Trait fügt jedem Fehler beschreibende Nachrichten hinzu.

main.rsrust

// Application error handling with anyhow 1.0

use anyhow::{Context, Result, bail, ensure};

fn load_database_url() -> Result<String> {
    std::env::var("DATABASE_URL")
        .context("DATABASE_URL environment variable not set")
}

fn connect_to_database(url: &str) -> Result<DatabaseConnection> {
    ensure!(!url.is_empty(), "database URL cannot be empty");

    let conn = DatabaseConnection::new(url)
        .context("failed to establish database connection")?;

    if !conn.is_healthy() {
        bail!("database connection unhealthy after establishment");
    }

    Ok(conn)
}

fn main() -> Result<()> {
    let url = load_database_url()?;
    let conn = connect_to_database(&url)
        .context("application startup failed")?;

    // Context chains create readable error traces:
    // Error: application startup failed
    // Caused by:
    //     0: failed to establish database connection
    //     1: connection refused

    Ok(())
}

struct DatabaseConnection;
impl DatabaseConnection {
    fn new(_url: &str) -> Result<Self> { Ok(Self) }
    fn is_healthy(&self) -> bool { true }
}

Die context()-Methode umhüllt Fehler mit zusätzlichen Informationen und erstellt eine Kette, die beim Debugging hilft. Das bail!-Makro bietet einen vorzeitigen Ausstieg mit einer formatierten Fehlermeldung, während ensure! als Assertion fungiert, die einen Fehler zurückgibt, anstatt zu paniken.

Bereit für deine Rust-Interviews?

Übe mit unseren interaktiven Simulatoren, Flashcards und technischen Tests.

Rust erkunden

Kombination von thiserror und anyhow in realen Projekten

Bibliotheken exponieren strukturierte Fehler über thiserror für die programmatische Behandlung durch Konsumenten. Anwendungen umhüllen diese Fehler mit anyhow für menschenlesbare Ausgabe. Diese Trennung hält APIs sauber und wahrt gleichzeitig die Debugbarkeit.

lib.rs - Library code with thiserrorrust

// Exposes typed errors for programmatic handling

use thiserror::Error;

#[derive(Error, Debug)]
pub enum PaymentError {
    #[error("insufficient funds: required {required}, available {available}")]
    InsufficientFunds { required: u64, available: u64 },

    #[error("card declined: {reason}")]
    CardDeclined { reason: String },

    #[error("payment provider unavailable")]
    ProviderUnavailable(#[source] reqwest::Error),
}

pub fn process_payment(amount: u64) -> Result<Receipt, PaymentError> {
    // Library returns specific, matchable error types
    Err(PaymentError::InsufficientFunds {
        required: amount,
        available: 50,
    })
}

pub struct Receipt;

main.rs - Application code with anyhowrust

// Wraps library errors with context

use anyhow::{Context, Result};
use my_payment_lib::{process_payment, PaymentError};

fn checkout(cart_total: u64) -> Result<()> {
    match process_payment(cart_total) {
        Ok(_receipt) => Ok(()),
        Err(PaymentError::InsufficientFunds { required, available }) => {
            // Handle specific case differently
            println!("Add {} to your balance", required - available);
            Ok(())
        }
        Err(e) => Err(e).context("checkout payment processing failed"),
    }
}

Dieses Muster ermöglicht es Aufrufern, auf spezifische Varianten zu matchen, wenn eine Wiederherstellung möglich ist, während sie dennoch von reichhaltigem Fehlerkontext profitieren, wenn Fehler nach oben propagiert werden. Die Rust-Community hat sich weitgehend auf diesen Ansatz standardisiert, wie in den Rust API-Richtlinien diskutiert.

Fehlerbehandlungsmuster für asynchronen Code

Async-Funktionen geben Result genau wie synchrone zurück. Der ?-Operator funktioniert identisch innerhalb von async-Blöcken, und sowohl thiserror als auch anyhow integrieren sich ohne Modifikation.

async_errors.rsrust

// Error handling in async Rust with Tokio

use anyhow::{Context, Result};
use std::time::Duration;

async fn fetch_user_data(user_id: u64) -> Result<UserData> {
    let response = reqwest::get(format!("https://api.example.com/users/{}", user_id))
        .await
        .context("HTTP request to user API failed")?;

    let status = response.status();
    if !status.is_success() {
        anyhow::bail!("user API returned status {}", status);
    }

    let data: UserData = response
        .json()
        .await
        .context("failed to parse user data JSON")?;

    Ok(data)
}

async fn fetch_with_retry(user_id: u64, attempts: u32) -> Result<UserData> {
    let mut last_error = None;

    for attempt in 1..=attempts {
        match fetch_user_data(user_id).await {
            Ok(data) => return Ok(data),
            Err(e) => {
                last_error = Some(e);
                if attempt < attempts {
                    tokio::time::sleep(Duration::from_millis(100 * attempt as u64)).await;
                }
            }
        }
    }

    Err(last_error.unwrap()).context(format!("failed after {} attempts", attempts))
}

#[derive(serde::Deserialize)]
struct UserData {
    name: String,
}

Bei der Kombination mehrerer asynchroner Operationen empfiehlt sich try_join! aus tokio oder futures, um sie gleichzeitig auszuführen und dabei den ersten Fehler zu propagieren. Für verwandte Konzepte bietet das Modul async/await Interviewfragen weitere Einblicke.

Downcasting und Fehlerinspektion

Sowohl anyhow::Error als auch Box<dyn Error> unterstützen Downcasting zur Wiederherstellung des ursprünglichen Fehlertyps. Dies ermöglicht das Protokollieren spezifischer Details bei gleichzeitiger Propagierung generischer Fehler.

downcasting.rsrust

// Inspecting wrapped error types

use anyhow::{Context, Result};
use std::io;

fn log_and_propagate(result: Result<()>) -> Result<()> {
    if let Err(ref e) = result {
        // Check if the root cause is a specific type
        if let Some(io_err) = e.downcast_ref::<io::Error>() {
            match io_err.kind() {
                io::ErrorKind::NotFound => {
                    tracing::warn!("file not found, using defaults");
                }
                io::ErrorKind::PermissionDenied => {
                    tracing::error!("permission denied - check file ownership");
                }
                _ => {
                    tracing::error!("IO error: {:?}", io_err);
                }
            }
        }
    }
    result
}

Downcasting überbrückt die Lücke zwischen generischer Fehlerbehandlung und spezifischer Wiederherstellungslogik. Es sollte sparsam eingesetzt werden—wenn häufiges Downcasting vorkommt, sollte geprüft werden, ob ein typisiertes Fehler-Enum besser geeignet wäre.

Konvertierung zwischen Option und Result

Die Standardbibliothek bietet Methoden zur Konvertierung zwischen Option und Result, was eine reibungslose Komposition ermöglicht, wenn verschiedene APIs unterschiedliche Muster verwenden.

conversions.rsrust

// Option and Result interoperability

fn get_env_port() -> Option<u16> {
    std::env::var("PORT")
        .ok()  // Result -> Option (discards error)
        .and_then(|s| s.parse().ok())
}

fn get_env_port_with_error() -> Result<u16, String> {
    std::env::var("PORT")
        .map_err(|_| "PORT not set".to_string())?
        .parse()
        .map_err(|_| "PORT is not a valid number".to_string())
}

fn lookup_and_parse(map: &std::collections::HashMap<String, String>, key: &str) -> Result<u16, String> {
    map.get(key)
        .ok_or_else(|| format!("key '{}' not found", key))?  // Option -> Result
        .parse()
        .map_err(|e| format!("parse error for '{}': {}", key, e))
}

Die ok()-Methode verwirft Fehlerdetails, wenn nur die Anwesenheit relevant ist. Die Methoden ok_or() und ok_or_else() konvertieren None in einen benutzerdefinierten Fehler und ermöglichen die ?-Propagierung von Option-Werten. Diese Muster erscheinen häufig in Pattern Matching Interviewfragen.

Performanceüberlegungen

Die Fehlerbehandlung in Rust verursacht keine Laufzeitkosten auf dem Erfolgspfad. Result und Option sind stack-allokierte Enums mit deterministischer Größe. Der Compiler optimiert Prüfungen weg, wenn er beweisen kann, dass ein Zweig unerreichbar ist.

| Ansatz | Kosten Erfolgspfad | Kosten Fehlerpfad | |--------|-------------------|-------------------| | Result/Option | Null | Stack-Unwinding (günstig) | | panic! | Null | Vollständiges Stack-Unwinding + Cleanup | | C++ Exceptions | Null (meist) | Teure Heap-Allokation + RTTI |

unwrap() und expect() sollten in Bibliothekscode vermieden werden—sie sind für Fälle reserviert, in denen ein Fehlschlag tatsächlich einen Bug anzeigt. Für leistungskritische Pfade, auf denen Fehler häufig auftreten, empfiehlt sich die Verwendung von Enums mit Inline-Daten anstelle von heap-allozierten Fehlertypen.

Fazit

Result<T, E> behandelt behebbare Fehler; Option<T> behandelt Abwesenheit—beide erzwingen Behandlung zur Kompilierzeit
Der ?-Operator propagiert Fehler prägnant und erfordert From-Trait-Implementierungen für Typkonvertierung
thiserror generiert strukturierte Fehlertypen für Bibliotheken ohne Boilerplate
anyhow bietet kontextuelle Fehlerketten für Anwendungen mit Unterstützung für context(), bail! und ensure!
Beides kombinieren: Bibliotheken exponieren typisierte Fehler über thiserror, Anwendungen umhüllen sie mit anyhow
Asynchroner Code verwendet identische Muster—? funktioniert in async-Blöcken ohne Modifikation
ok_or() konvertiert Option zu Result; ok() für die Umkehrung
Umhüllte Fehler nur dann downcasten, wenn spezifische Wiederherstellungslogik den Originaltyp erfordert

Fang an zu üben!

Teste dein Wissen mit unseren Interview-Simulatoren und technischen Tests.

Kostenloses Konto erstellen

Rust Error Handling 2026: Result, Option, thiserror und anyhow im Praxiseinsatz