Concevoir ses erreurs : thiserror vs anyhow Designing your errors: thiserror vs anyhow

Un Err qui ne dit rien, c'est un None déguisé.An Err that says nothing is a None in disguise.

Le numéro précédent a donné le contenant — Result, et le ? pour le faire circuler. Mais le E est resté vague. Or le pouvoir de Result vient justement de ce que l'échec transporte une information : sans elle, on retombe au niveau d'Option, où il n'y a qu'un « ça n'a pas marché ». Une erreur utile dit trois choses : ce qui a échoué (la cause), avec quel contexte (le fichier, la ligne, l'identifiant), et de manière que l'appelant puisse soit réagir au cas près, soit l'afficher proprement. Concevoir ses erreurs, c'est dessiner ce type E — et le premier réflexe est d'en faire un enum, une variante par façon d'échouer.The previous issue gave the container — Result, and the ? to move it around. But the E stayed vague. Yet Result's power comes precisely from failure carrying information: without it, you fall back to Option's level, where there's only a 'it didn't work'. A useful error says three things: what failed (the cause), with what context (the file, the line, the id), and in a way that lets the caller either react case by case or display it cleanly. Designing your errors means drawing that E type — and the first reflex is to make it an enum, one variant per way to fail.

// Un type d'erreur qui DIT ce qui a échoué — une variante par cause
enum ChargementError {
    FichierAbsent(PathBuf),       // on sait QUEL fichier manquait
    TomlInvalide(toml::Error),    // on garde la cause d'origine
    PortManquant,                 // une condition métier nommée
}

// l'appelant peut réagir au cas près :
match charger_config() {
    Err(ChargementError::FichierAbsent(p)) => creer_defaut(&p),  // récupérable
    Err(e) => return Err(e),                                     // le reste remonte
    Ok(c)  => c,
}

Une erreur en texte se lit. Une erreur en type se traite.A text error gets read. A typed error gets handled.

La voie de la facilité, c'est l'erreur en String : un message formaté, renvoyé tel quel. Ça compile, ça s'affiche, et tant qu'on ne fait qu'afficher, ça suffit presque. Le problème surgit dès qu'on veut réagir : reprendre sur tel cas, retenter sur tel autre, ignorer le troisième. Avec un message texte, la seule façon de distinguer les causes est d'en parser le contenu — un couplage fragile qui casse à la première reformulation. L'enum d'erreur garde chaque cause comme une variante distincte : l'appelant match dessus, le compilateur vérifie l'exhaustivité, et le message d'affichage devient une projection du type, pas sa seule réalité.The easy path is the String error: a formatted message, returned as-is. It compiles, it displays, and as long as you only display, it almost suffices. The problem arises the moment you want to react: resume on this case, retry on that one, ignore the third. With a text message, the only way to tell causes apart is to parse its content — a fragile coupling that breaks at the first rewording. The error enum keeps each cause as a distinct variant: the caller matches on it, the compiler checks exhaustiveness, and the display message becomes a projection of the type, not its only reality.

// L'erreur « stringly typed » — un message, et rien d'autre
fn charger(chemin: &str) -> Result<Config, String> {
    let texte = std::fs::read_to_string(chemin)
        .map_err(|e| format!("lecture impossible: {e}"))?;
    toml::from_str(&texte)
        .map_err(|e| format!("toml invalide: {e}"))
}

// l'appelant ne peut que l'AFFICHER. Pour réagir « si le fichier manque,
// crée-le », il devrait fouiller la chaîne — fragile, et cassé à la
// première reformulation du message.

Chaque map_err écrase une erreur riche — une io::Error qui sait si le fichier manquait ou si l'accès était refusé — en une simple phrase. L'appelant hérite d'un String : il peut le logger, pas raisonner dessus. Le jour où il veut « recréer le fichier s'il est absent », il doit chercher un bout de texte dans le message, et son code casse dès qu'on retouche la formulation. On a transformé une donnée structurée en prose, irréversiblement.Each map_err crushes a rich error — an io::Error that knows whether the file was missing or access denied — into a plain sentence. The caller inherits a String: they can log it, not reason about it. The day they want to 'recreate the file if it's missing', they must search for a snippet of text in the message, and their code breaks the moment you tweak the wording. You turned structured data into prose, irreversibly.

thiserror : l'enum d'erreur, sans le boilerplate de l'enum d'erreur.thiserror: the error enum, without the error enum's boilerplate.

Un bon type d'erreur doit faire trois choses : s'afficher lisiblement (implémenter Display), s'intégrer à l'écosystème (implémenter le trait Error), et se laisser produire facilement par ? (avoir des From depuis les erreurs sous-jacentes). À la main, c'est trois impl par variante — un mur de code répétitif qui décourage de bien typer ses erreurs. La crate thiserror génère tout cela depuis des annotations. On décrit l'enum et ses messages ; la macro dérive Display, Error, et les From marqués #[from]. Le type d'erreur précis redevient bon marché — et donc, enfin, celui qu'on écrit par défaut.A good error type must do three things: display readably (implement Display), integrate with the ecosystem (implement the Error trait), and be easy to produce via ? (have From conversions from the underlying errors). By hand, that's three impls per variant — a wall of repetitive code that discourages typing your errors well. The thiserror crate generates all of it from annotations. You describe the enum and its messages; the macro derives Display, Error, and the From conversions marked #[from]. The precise error type becomes cheap again — and so, at last, the one you write by default.

use thiserror::Error;

#[derive(Debug, Error)]
enum ChargementError {
    #[error("lecture impossible: {0}")]      // ce que verra l'humain (Display)
    Lecture(#[from] std::io::Error),          // #[from] : conversion automatique

    #[error("toml invalide: {0}")]
    Toml(#[from] toml::Error),

    #[error("le champ 'port' est absent")]
    PortManquant,                             // une variante sans cause source
}

fn charger(chemin: &str) -> Result<Config, ChargementError> {
    let texte = std::fs::read_to_string(chemin)?;   // io::Error -> ChargementError
    let config: Config = toml::from_str(&texte)?;   // toml::Error -> ChargementError
    config.port.ok_or(ChargementError::PortManquant)?;
    Ok(config)
}
// plus un seul map_err : #[from] a généré les From, le ? les appelle.
// l'enum reste matchable par l'appelant, ET s'affiche proprement.

Le grand partage : une bibliothèque laisse réagir, une application rapporte.The great divide: a library lets you react, an application reports.

Deux crates dominent la gestion d'erreur, et le réflexe « laquelle ? » n'a qu'une bonne réponse : ça dépend de qui appelle. thiserror produit un enum précis, matchable — c'est l'outil d'une bibliothèque, parce que ses consommateurs sont inconnus et voudront peut-être réagir à tel cas. anyhow produit une erreur unique et opaque, qui agrège n'importe quelle source et empile du contexte — c'est l'outil d'une application, d'un binaire au sommet de la pile, où l'on ne « réagit » presque jamais et où l'on veut surtout un rapport d'échec lisible. Le piège n'est pas de choisir l'un ou l'autre, mais de les inverser.Two crates dominate error handling, and the reflex 'which one?' has only one good answer: it depends on who calls. thiserror produces a precise, matchable enum — it's a library's tool, because its consumers are unknown and may want to react to a given case. anyhow produces a single, opaque error that aggregates any source and stacks context — it's an application's tool, a binary at the top of the stack, where you almost never 'react' and mostly want a readable failure report. The trap isn't choosing one or the other, but swapping them.

// Une BIBLIOTHÈQUE qui renvoie anyhow::Error
use anyhow::Context;   // .context() vient du trait, pas de l'erreur

pub fn parse_facture(src: &str) -> anyhow::Result<Facture> {
    let doc = parse_xml(src).context("xml malformé")?;
    let total = doc.total().context("total manquant")?;
    Ok(Facture { total })
}

// l'appelant de ta lib reçoit un anyhow::Error : une erreur opaque,
// agrégée. Il peut l'afficher, pas la MATCHER. Impossible d'écrire
// « si la facture n'a pas de total, demande-le à l'utilisateur ».
// tu as imposé À TOUS TES CONSOMMATEURS de ne jamais réagir.

En renvoyant anyhow::Error depuis une bibliothèque, tu prives tous tes appelants de la capacité de distinguer les causes. anyhow efface le type concret derrière une erreur unique : parfait quand on ne fera qu'afficher, désastreux quand quelqu'un, en aval, aurait voulu reprendre sur un cas précis. Une lib ne connaît pas ses consommateurs ; elle ne doit donc pas décider à leur place qu'ils ne réagiront jamais.By returning anyhow::Error from a library, you deprive all your callers of the ability to tell causes apart. anyhow erases the concrete type behind a single error: perfect when you'll only display, disastrous when someone downstream would have wanted to resume on a precise case. A library doesn't know its consumers; so it must not decide for them that they'll never react.

// La LIB expose un enum précis (thiserror) — l'appelant peut trier
#[derive(Debug, thiserror::Error)]
pub enum FactureError {
    #[error("xml malformé: {0}")]
    Xml(#[from] XmlError),
    #[error("total manquant")]
    TotalManquant,
}
pub fn parse_facture(src: &str) -> Result<Facture, FactureError> { /* ... */ }

// L'APPLICATION (le binaire) agrège tout en anyhow + du contexte
fn main() -> anyhow::Result<()> {
    let src = std::fs::read_to_string("facture.xml")?;
    let f = parse_facture(&src).context("chargement de la facture")?;
    println!("{}", f.total);
    Ok(())   // ici personne ne « réagit » : on veut un rapport lisible.
}

La bibliothèque expose un enum thiserror : ses consommateurs peuvent match. L'application, elle, se sert d'anyhow pour agréger toutes ces erreurs précises en une seule, et empiler du contexte (.context("…")) à chaque étage — ce qui produira un rapport « chargement de la facture → total manquant » exploitable par un humain. Chaque outil à sa place : la lib préserve l'information, l'app la met en forme.The library exposes a thiserror enum: its consumers can match. The application, in turn, uses anyhow to aggregate all those precise errors into one, and stack context (.context("…")) at each level — yielding a human-usable report 'loading the invoice → missing total'. Each tool in its place: the lib preserves the information, the app shapes it.