Antwoord.

Rust is gebaseerd op expliciete foutafhandeling: uitzonderingen zijn afwezig, in plaats daarvan wordt de terugkeerwaarde Result<T, E> gebruikt. Dit zorgt voor de veiligheid en voorspelbaarheid van de code.

Achtergrond:

Veel talen hebben gekozen voor uitzonderingen, wat leidde tot onverwachte situaties en de noodzaak om uitzonderingen expliciet in runtime af te handelen. Rust heeft vanaf het begin ingezet op typecontrole; alle fouten moeten deel uitmaken van de functiehandtekening.

Probleem:

De belangrijkste taak is om code te schrijven waarin fouten niet genegeerd of gemaskeerd worden, er zijn geen "crashende" functies, maar de code blijft compact en leesbaar. Het is nodig om fouten correct omhoog te geven zonder informatie over hun type te verliezen en zonder de logica te verwarren.

Oplossing:

Het belangrijkste hulpmiddel is het type Result<T, E> en de operator ?, die automatisch het resultaat "uitpakt": bij een fout vindt er onmiddellijk een exit uit de functie plaats met een foutmelding, en bij succes wordt de waarde teruggegeven.

Voorbeeldcode:

fn read_number(file: &str) -> Result<i32, std::io::Error> {
    let content = std::fs::read_to_string(file)?;
    let num: i32 = content.trim().parse()?;
    Ok(num)
}

Belangrijke kenmerken:

Expliciete declaratie van alle potentiële fouten in de handtekening
De operator ? vereenvoudigt de nesting (verwijdert if-let/unwrap/expect)
Fouten kunnen eenvoudig "gewikkeld" of getransformeerd worden (via .map_err() en andere methoden)

Vragen met een haakje.

Mag je ? gebruiken in functies die Unit (void) teruggeven?

Nee, de operator ? is alleen toegestaan binnen functies die Result of Option retourneren. Als een functie () retourneert, kan ? niet gebruikt worden.

Wat gebeurt er als de fouttypes in meerdere aanroepen met ? verschillend zijn?

Dit resulteert in een compilatiefout: het fouttype moet eenduidig worden gedefinieerd. Je moet alle fouten ofwel naar één type omzetten via .map_err() of thiserror gebruiken, of een enum-wrapper op API-niveau beschrijven. Voorbeeld:

fn foo() -> Result<_, MyError> {
   let a = bar()?;
   let b = baz().map_err(MyError::Baz)?;
   Ok(…)
}

Wat is gevaarlijk aan .unwrap() in de interne logica?

Er is een verbreide verkeerde opvatting dat je unwrap() gerust in de "hoofd" code kunt gebruiken, omdat "het absoluut niet zal crashen". In werkelijkheid zal zelfs een kleine onzichtbare fout leiden tot een runtime-paniek – de veiligheid van het programma zal in gevaar komen.

Typische fouten en anti-patronen

Het onderscheppen van alle fouten via unwrap/expect, vooral in de interne logica
Verlies van context bij map_err(|_| …), wanneer een fout wordt afgesloten zonder de originele informatie te behouden
Overmatige nesting bij handmatige behandeling van elke fout zonder ?

Voorbeeld uit het leven

Negatief geval

In productiecode bleven veel unwrap() staan na snelle debugging. Uiteindelijk crasht de applicatie bij elke parsefout vanwege onjuiste invoer van de gebruiker.

Voordelen:

Snelle debugging

Nadelen:

Potentiële crash van de applicatie, moeilijk om de oorzaak te vinden

Positief geval

Gebruikten de volledige stack Result<T, E> met expliciete beschrijving van fouten en gebruikten alleen ? en .map_err(), waarbij alle informatie over de fout behouden bleef.