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,
}