Result & l'opérateur ?, ou l'erreur comme valeur Result & the ? operator, or the error as a value

L'échec n'est pas une interruption surprise. C'est une valeur de retour.Failure isn't a surprise interruption. It's a return value.

Le Vol 3 a appris à rendre l'illégal impossible à écrire. Mais toutes les erreurs ne sont pas des bugs à proscrire : un fichier qui n'existe pas, un réseau qui tombe, une saisie invalide sont des événements normaux. La plupart des langages les signalent par une exception — un canal parallèle, invisible dans la signature, qui saute par-dessus ton code jusqu'à ce que quelqu'un l'attrape, ou pas. Rust prend le chemin inverse : l'échec est une valeur ordinaire, Result<T, E>, posée dans le type de retour. Le même enum que partout — Ok ou Err — au cœur de la gestion d'erreur la plus honnête qui soit.Vol 3 taught us to make the illegal impossible to write. But not every error is a bug to forbid: a file that isn't there, a network that drops, invalid input are normal events. Most languages signal them with an exception — a parallel channel, invisible in the signature, that leaps over your code until someone catches it, or doesn't. Rust takes the opposite path: failure is an ordinary value, Result<T, E>, placed in the return type. The same enum as everywhere — Ok or Err — at the heart of the most honest error handling there is.

enum Result<T, E> {   // exactement la forme d'Option, mais l'absence porte une RAISON
    Ok(T),            // le succès, qui transporte la valeur attendue
    Err(E),           // l'échec, qui transporte ce qui a mal tourné
}

// lire un fichier peut échouer : le type de retour le DIT
fn lire_config(chemin: &str) -> Result<String, std::io::Error> { /* ... */ }

let config = lire_config("app.toml");   // config est Result<String, Error>
// impossible d'utiliser le String sans d'abord regarder le cas Err en face.

L'exception saute par-dessus ton code. Result le traverse à découvert.The exception leaps over your code. Result goes through it in the open.

Une exception voyage dans un canal parallèle : elle ne figure pas dans le type de retour, elle remonte la pile d'appels en sautant par-dessus chaque fonction jusqu'à un catch — ou jusqu'au crash si personne ne l'attrape. Le lecteur d'une signature ne sait pas ce qui peut échouer ; il faut connaître l'implémentation, et celle de tout ce qu'elle appelle. Result fait l'inverse : l'échec est un cas du type de retour, visible, et le compilateur refuse de te laisser l'oublier. La différence n'est pas stylistique — c'est la différence entre une erreur qu'on peut ignorer par accident et une erreur qu'on doit décider de traiter.An exception travels in a parallel channel: it doesn't appear in the return type, it climbs the call stack leaping over each function until a catch — or until the crash if no one catches it. The reader of a signature doesn't know what can fail; you have to know the implementation, and that of everything it calls. Result does the opposite: failure is a case of the return type, visible, and the compiler refuses to let you forget it. The difference isn't stylistic — it's the difference between an error you can ignore by accident and an error you must decide to handle.

// Style « exception » (pseudo-code à la Java/Python)
fn charger_utilisateur(id: u32) -> Utilisateur {
    let ligne = db.query(id);        // peut lever DbError — RIEN ne le dit
    let u = parse(ligne);            // peut lever ParseError — RIEN ne le dit
    u
}

charger_utilisateur(42);             // ✓ COMPILE. l'échec est invisible.
// la signature promet un Utilisateur. elle ment : elle peut aussi
// faire exploser la pile d'appels par un canal que le type ne montre pas.

La signature annonce -> Utilisateur, mais deux appels peuvent faire dérailler l'exécution sans que rien, au point d'appel, ne l'indique. Pour savoir ce qui peut échouer, il faut ouvrir le corps de la fonction — et celui de query, et de parse, récursivement. L'échec existe, mais il s'est rendu invisible. C'est précisément l'exception non gérée que tant de programmes traînent : non par malveillance, mais parce que le type ne forçait personne à y penser.The signature announces -> Utilisateur, but two calls can derail execution without anything at the call site indicating it. To know what can fail, you must open the body of the function — and that of query, and of parse, recursively. The failure exists, but it made itself invisible. This is exactly the unhandled exception so many programs carry: not out of malice, but because the type forced no one to think about it.

L'opérateur ? : la propagation d'une exception, mais écrite.The ? operator: an exception's propagation, but spelled out.

Sans aide, propager une erreur à la main est verbeux : chaque appel faillible devient un match qui, en cas d'Err, retourne. Le code se noie sous la plomberie, et le chemin heureux disparaît. L'opérateur ? est la réponse de Rust : placé après une expression qui rend un Result, il extrait le Ok et continue, ou retourne l'Err immédiatement à l'appelant. On retrouve la légèreté de l'exception — une ligne droite qui se lit comme si rien ne pouvait échouer — sans en perdre l'honnêteté : chaque ? est un point de sortie visible, et la signature porte toujours le type d'erreur.Without help, propagating an error by hand is verbose: each fallible call becomes a match that, on Err, returns. The code drowns in plumbing, and the happy path vanishes. The ? operator is Rust's answer: placed after an expression yielding a Result, it extracts the Ok and continues, or returns the Err immediately to the caller. You regain the exception's lightness — a straight line that reads as if nothing could fail — without losing its honesty: each ? is a visible exit point, and the signature still carries the error type.

// Ce qu'on écrit
let octets = std::fs::read(chemin)?;

// Ce que ? veut dire, exactement
let octets = match std::fs::read(chemin) {
    Ok(v)  => v,                 // succès : on extrait la valeur, on continue
    Err(e) => return Err(e.into()),  // échec : on retourne TOUT DE SUITE
};
// ? = « donne-moi le Ok, ou propage l'Err à l'appelant ». Un caractère.

fn charger(chemin: &str) -> Result<Config, AppError> {
    let texte = std::fs::read_to_string(chemin)?;   // io::Error -> AppError
    let config: Config = toml::from_str(&texte)?;   // toml::Error -> AppError
    Ok(config)
}
// deux types d'erreur différents, une seule signature : le ? appelle
// From pour convertir chaque erreur en AppError au passage. La chaîne
// se lit comme le chemin heureux ; les échecs sortent par le côté.

Le .unwrap() partout : l'exception non gérée, réinventée.The .unwrap() everywhere: the unhandled exception, reinvented.

Le compilateur refuse d'extraire la valeur d'un Result sans traiter l'Err. Face à ce mur, la tentation est immédiate : .unwrap(). Une méthode qui dit « donne-moi le Ok, et si c'est Err, fais paniquer le programme ». Le code compile, l'erreur disparaît de la vue — et l'on vient de rétablir exactement ce que Result voulait nous épargner : un échec attendu qui termine le programme par un crash, sans contexte, au pire moment. Le compilateur t'avait tendu une question — « que fais-tu si ça échoue ? » — et .unwrap() y répond « je plante ». Sur un bug, c'est parfois correct. Sur un fichier manquant, c'est une faute.The compiler refuses to extract a Result's value without handling the Err. Faced with this wall, the temptation is immediate: .unwrap(). A method that says 'give me the Ok, and if it's Err, panic the program'. The code compiles, the error vanishes from sight — and you've just restored exactly what Result meant to spare you: an expected failure that ends the program in a crash, with no context, at the worst moment. The compiler had handed you a question — 'what do you do if this fails?' — and .unwrap() answers 'I crash'. On a bug, that's sometimes right. On a missing file, it's a mistake.

// .unwrap() partout « pour faire passer le compilateur »
fn charger_port() -> u16 {
    let texte = std::fs::read_to_string("config").unwrap();  // panique si absent
    let config: Config = toml::from_str(&texte).unwrap();    // panique si invalide
    config.port.unwrap()                                     // panique si manquant
}
// le compilateur était satisfait. l'utilisateur, lui, reçoit un crash brut
// sur un fichier manquant — exactement l'exception non gérée qu'on fuyait.

Chaque .unwrap() transforme un échec attendu en panique. Le fichier de config peut manquer, être mal formé, ne pas contenir de port : ce sont des situations normales d'exploitation, pas des bugs. Les traiter par .unwrap(), c'est dire au programme « si le monde réel se présente, meurs ». On a fait taire le compilateur sans répondre à sa question — et on a rétabli l'exception non gérée que tout le volume cherche à éliminer.Each .unwrap() turns an expected failure into a panic. The config file may be missing, malformed, hold no port: these are normal operating situations, not bugs. Handling them with .unwrap() tells the program 'if the real world shows up, die'. You silenced the compiler without answering its question — and restored the unhandled exception the whole volume sets out to eliminate.

// On traite l'échec attendu comme une valeur, et on le propage
fn charger_port() -> Result<u16, AppError> {
    let texte = std::fs::read_to_string("config")?;   // l'absence remonte, typée
    let config: Config = toml::from_str(&texte)?;     // l'invalidité remonte aussi
    config.port.ok_or(AppError::PortManquant)         // Option -> Result, avec raison
}
// l'appelant choisit : valeur par défaut, message clair, nouvelle tentative.
// rien ne panique sur une condition que le monde réel produit normalement.

Le ? remonte chaque échec à l'appelant, et ok_or transforme l'Option du port en Result en lui donnant une raison. La fonction redevient honnête : sa signature dit qu'elle peut échouer, et le code de plus haut niveau — celui qui sait quoi faire d'un défaut de config — décide. La règle n'est pas « jamais d'unwrap » mais « pas d'unwrap sur une erreur attendue ». Le n°3 dira où unwrap et panic sont, eux, le bon outil : sur un invariant brisé, c'est-à-dire un vrai bug.The ? bubbles each failure to the caller, and ok_or turns the port's Option into a Result by giving it a reason. The function is honest again: its signature says it can fail, and higher-level code — the one that knows what to do with a config fault — decides. The rule isn't 'never unwrap' but 'no unwrap on an expected error'. Issue n°3 will say where unwrap and panic are the right tool: on a broken invariant — that is, a real bug.