panic, unwrap & les invariants panic, unwrap & invariants

Toutes les erreurs ne se gèrent pas. Certaines doivent tout arrêter.Not every error is to be handled. Some must stop everything.

Deux numéros ont martelé : ne panique pas, propage. On pourrait en conclure qu'un programme bien écrit ne panique jamais — ce serait l'erreur inverse du unwrap partout, mais une erreur quand même. La distinction qui ouvrait le volume revient ici pour le clore : une erreur attendue (fichier absent, réseau coupé, saisie invalide) appartient au Result ; un bug — un invariant qu'on s'était promis et qui se rompt — n'a rien à y faire. Quand un état déclaré impossible survient, continuer en faisant semblant est pire que s'arrêter : on propagerait des données corrompues. Là, paniquer n'est pas un échec de conception, c'est la conception.Two issues hammered: don't panic, propagate. You might conclude a well-written program never panics — that would be the mirror of unwrap-everywhere, but a mistake all the same. The distinction that opened the volume returns to close it: an expected error (missing file, dropped network, invalid input) belongs in a Result; a bug — an invariant you promised yourself that breaks — has no place there. When a state declared impossible occurs, carrying on pretending is worse than stopping: you'd propagate corrupted data. There, panicking isn't a design failure, it's the design.

// ERREUR ATTENDUE — le monde réel, prévisible → Result
fn lire(chemin: &str) -> Result<String, io::Error> { /* le fichier peut manquer */ }

// BUG — un invariant que MON code s'était promis → panic
fn moyenne(notes: &[f64]) -> f64 {
    assert!(!notes.is_empty(), "moyenne() appelée sur une tranche vide");
    notes.iter().sum::<f64>() / notes.len() as f64   // len() == 0 serait une faute
}

// la frontière : « le monde extérieur peut-il produire ça normalement ? »
//   oui → Result.   non, c'est MA promesse qui se rompt → panic.

Un Result pour un bug pollue tous les appelants — et masque le vrai problème.A Result for a bug pollutes every caller — and hides the real problem.

Après deux numéros à fuir la panique, le réflexe devient excessif : on enveloppe tout en Result, y compris ce qui ne peut pas légitimement échouer. Le résultat est contre-intuitif. Renvoyer un Err pour un cas qui ne devrait jamais survenir oblige chaque appelant à gérer une branche fantôme — un cas qui n'arrive jamais, mais qu'on doit matcher partout, à jamais. Pire : le jour où ce cas survient quand même (parce qu'il y avait bien un bug), il ne fait pas de bruit ; il se propage comme une erreur ordinaire, et l'arrêt n'arrive que loin de la cause. Paniquer est ici le choix le plus sûr — il garde la signature honnête et fait éclater le bug à sa source.After two issues fleeing panic, the reflex turns excessive: you wrap everything in a Result, including what cannot legitimately fail. The result is counter-intuitive. Returning an Err for a case that should never happen forces every caller to handle a phantom branch — a case that never occurs, yet must be matched everywhere, forever. Worse: the day that case does occur (because there really was a bug), it makes no noise; it propagates like an ordinary error, and the stop comes only far from the cause. Panicking is the safer choice here — it keeps the signature honest and bursts the bug at its source.

// On déguise un BUG en erreur attendue : un Err « ça ne peut pas arriver »
enum FeuError { EtatImpossible }

fn suivant(feu: Feu) -> Result<Feu, FeuError> {
    match feu {
        Feu::Vert  => Ok(Feu::Orange),
        Feu::Orange => Ok(Feu::Rouge),
        Feu::Rouge => Ok(Feu::Vert),
        _ => Err(FeuError::EtatImpossible),   // une branche qui ne devrait JAMAIS exister
    }
}
// chaque appelant doit désormais gérer un cas qui n'arrive jamais —
// et le vrai bug (un Feu corrompu) remonte, masqué, jusqu'on ne sait où.

La branche _ => Err(...) a l'air prudente, elle est nuisible. Elle impose à tous de traiter un échec qui n'arrive jamais en fonctionnement correct, alourdissant chaque appel d'un cas mort. Et elle désamorce la sécurité du Vol 3 : tant que le _ est là, ajouter une variante à Feu ne casse plus la compilation — le compilateur ne peut plus t'avertir. On a échangé une vérification statique contre une erreur d'exécution silencieuse. C'est le pire des deux mondes.The _ => Err(...) branch looks cautious; it's harmful. It forces everyone to handle a failure that never happens in correct operation, weighing each call down with a dead case. And it defuses Vol 3's safety: as long as the _ is there, adding a variant to Feu no longer breaks compilation — the compiler can't warn you anymore. You traded a static check for a silent runtime error. It's the worst of both worlds.

La trousse de l'arrêt : panic!, expect, unreachable!, assert!.The stopping toolkit: panic!, expect, unreachable!, assert!.

Paniquer n'est pas un seul geste mais une petite famille d'outils, chacun pour une nuance d'invariant. panic! est l'arrêt brut, avec message. unwrap et expect extraient un Option ou un Result en pariant sur le cas heureux — expect en documentant le pari, unwrap muet. unreachable! marque une branche qu'on a prouvée morte. assert! vérifie une condition à chaque exécution ; debug_assert! seulement en debug, donc gratuit en release. Tous mènent au même endroit — un arrêt contrôlé — mais ils diffèrent par ce qu'ils disent au prochain humain qui lira la trace. Le bon outil est celui qui nomme l'invariant supposé.Panicking isn't a single gesture but a small family of tools, each for a shade of invariant. panic! is the blunt stop, with a message. unwrap and expect extract an Option or a Result betting on the happy case — expect documenting the bet, unwrap mute. unreachable! marks a branch you've proven dead. assert! checks a condition on every run; debug_assert! only in debug, hence free in release. All lead to the same place — a controlled stop — but they differ in what they tell the next human reading the trace. The right tool is the one that names the assumed invariant.

panic!("invariant rompu: {x}");   // arrêt explicite, avec message

let v = opt.expect("la config est validée en amont, ceci ne peut être None");
let v = opt.unwrap();             // = expect, mais SANS dire pourquoi — à éviter

match etat {
    A | B => agir(),
    _ => unreachable!("etat ne peut valoir que A ou B ici"),  // branche prouvée morte
}

assert!(index < len, "index {index} hors borne (len {len})");   // toujours vérifié
debug_assert!(liste.est_triee());  // vérifié en debug, retiré en release (coût nul)

// expect bien rédigé = un contrat, pas une excuse
let port: u16 = config.port
    .expect("port absent: charger_config() garantit sa présence");
//        ^ le message dit l'INVARIANT qu'on suppose, pas « ça a planté ».
// si ça panique un jour, le message pointe la promesse exacte qui a cédé.

Ne fais jamais paniquer ton programme sur l'erreur de quelqu'un d'autre.Never panic your program on someone else's error.

Le piège le plus courant du panic n'est pas d'y recourir trop — c'est d'y recourir au mauvais endroit : sur l'entrée de l'appelant. Une bibliothèque qui panique parce qu'on lui a passé une chaîne malformée fait tomber le programme de son consommateur pour une faute qui n'est pas la sienne. Or une saisie invalide, un fichier absent, un format douteux venant de l'extérieur sont des erreurs attendues, pas des bugs : ils appartiennent au Result. La panique est réservée à tes invariants internes — les promesses que seul ton propre code peut rompre. La frontière du numéro se précise : paniquer sur ce que tu t'étais promis, jamais sur ce que le monde t'a envoyé.Panic's most common trap isn't using it too much — it's using it in the wrong place: on the caller's input. A library that panics because it was passed a malformed string brings down its consumer's program for a fault that isn't theirs. Yet invalid input, a missing file, a dubious format from outside are expected errors, not bugs: they belong in a Result. Panic is reserved for your internal invariants — the promises only your own code can break. The issue's border sharpens: panic on what you promised yourself, never on what the world sent you.

// Une bibliothèque qui PANIQUE sur l'entrée de son appelant
pub fn parse_couleur(hex: &str) -> Couleur {
    assert!(hex.starts_with('#'), "format invalide");   // ✕ panique sur une saisie
    let n = u32::from_str_radix(&hex[1..], 16).unwrap(); // ✕ panique sur du texte
    Couleur::from_u32(n)
}

// l'appelant passe une chaîne venue d'un utilisateur. Si elle est malformée,
// TA lib fait tomber SON programme. Il ne peut ni rattraper, ni afficher
// un message propre : tu as transformé une erreur attendue en crash.

L'assert! et l'unwrap ici visent la mauvaise cible : l'entrée de l'appelant. Une couleur mal saisie est un événement parfaitement normal — l'utilisateur se trompe. En paniquant, la lib retire à son consommateur tout choix : pas de message clair, pas de nouvelle tentative, juste un crash pour une faute externe. C'est exactement le unwrap partout du n°1, mais aggravé : il est enfoui dans une dépendance, hors de portée de qui en subit les conséquences.The assert! and unwrap here aim at the wrong target: the caller's input. A mistyped color is a perfectly normal event — the user errs. By panicking, the lib strips its consumer of any choice: no clear message, no retry, just a crash for an external fault. It's exactly issue n°1's unwrap-everywhere, but worse: buried in a dependency, out of reach of whoever bears the consequences.

// L'entrée externe → Result. L'invariant interne → assert.
pub fn parse_couleur(hex: &str) -> Result<Couleur, CouleurError> {
    let reste = hex.strip_prefix('#').ok_or(CouleurError::PasDeDiese)?;
    if reste.len() != 6 { return Err(CouleurError::MauvaiseLongueur); }  // ← la borne
    let n = u32::from_str_radix(reste, 16).map_err(|_| CouleurError::PasDuHex)?;
    Ok(Couleur::from_u32(n))   // ← ICI seulement, n est garanti dans [0, 0xFFFFFF] :
}                              //   6 chiffres hexa ne peuvent pas dépasser 0xFFFFFF.

impl Couleur {
    fn from_u32(n: u32) -> Couleur {
        debug_assert!(n <= 0xFFFFFF, "from_u32 reçoit un n hors plage : bug interne");
        // assert sur NOTRE invariant, pas sur l'entrée du monde extérieur.
        Couleur(n)
    }
}

L'entrée externe est traitée comme ce qu'elle est — faillible — et remonte en Result ; l'appelant décide. Noter le contrôle de longueur : c'est lui qui établit l'invariant, en bornant n à six chiffres hexadécimaux. Sans lui, #FFFFFFFF passerait le from_str_radix et ferait sauter l'assert interne — une saisie utilisateur déguisée en bug maison. Le debug_assert!, lui, garde un invariant interne : une fois la longueur validée, n est forcément dans la plage, et si from_u32 reçoit autre chose, c'est notre bug — pas celui de l'utilisateur. La même fonction abrite donc les deux régimes : Result à la frontière du monde, assert au cœur de nos propres garanties.External input is treated as what it is — fallible — and bubbles up as a Result; the caller decides. Note the length check: it is what establishes the invariant, by bounding n to six hex digits. Without it, #FFFFFFFF would sail through from_str_radix and trip the internal assert — user input disguised as a homegrown bug. The debug_assert!, in turn, guards an internal invariant: once the length is validated, n must be in range, and if from_u32 gets anything else, that's our bug — not the user's. The same function thus houses both regimes: Result at the world's boundary, assert at the heart of our own guarantees.