Result, Option et l'opérateur ? : la gestion des erreurs en Rust

Ce que c'est

Result<T, E> est une énumération pourvue de Ok(T) et Err(E) ; Option<T> possède Some(T) et None. Il n'existe ni pointeur null ni déballage implicite : pour utiliser la valeur interne, le code doit passer par match, utiliser if let, ou appeler une méthode telle que unwrap_or, map, and_then ou ok_or. unwrap() et expect("...") extraient la valeur et paniquent sinon. Le Rust book décrit l'opérateur point d'interrogation : expr? appliqué à un Result fait sortir la fonction englobante de façon anticipée avec Err, après avoir fait passer l'erreur par le trait From vers le type d'erreur déclaré de la fonction ; sur un Option, il renvoie None. Il ne peut être utilisé que dans une fonction dont le type de retour est compatible, et main peut renvoyer Result<(), Box<dyn Error>> pour l'autoriser au niveau supérieur. La documentation de la bibliothèque standard indique que Result est annoté avec #[must_use], si bien qu'un Result ni lié ni utilisé déclenche un avertissement du compilateur.

Pourquoi c'est important

Un code fondé sur les exceptions laisse un échec remonter de façon invisible ; la signature d'une fonction Python ne dit rien de ce qu'elle peut lever. En Rust, la possibilité d'échec figure dans le type de retour, le compilateur refuse qu'elle soit oubliée, et le même mécanisme couvre les valeurs absentes, ce qui élimine la catégorie de bogues du None retourné de façon inattendue. Les panics existent, mais pour les invariants que l'entrée ne peut pas violer, pas pour les échecs attendus.

Comment l'appliquer

• Renvoyer Result pour tout ce qui touche aux entrées-sorties, à l'analyse ou aux données utilisateur ; renvoyer Option pour les recherches où l'absence est normale.
• Définir une énumération d'erreurs par crate ou module, avec une variante par cause, implémenter std::error::Error et Display, et implémenter From pour les erreurs sous-jacentes afin que ? les convertisse automatiquement ; des crates telles que thiserror génèrent ce code répétitif.
• Dans le code applicatif, un type d'erreur opaque portant du contexte (comme le fournit la crate anyhow) suffit souvent ; les bibliothèques devraient exposer des erreurs typées que les appelants peuvent filtrer par match.
• Réserver unwrap et expect aux tests et aux cas où l'invariant est énoncé dans le message d'expect.
• Utiliser des combinateurs pour les enchaînements courts et match quand les branches font des choses différentes.

Pièges

? à l'intérieur d'une closure s'applique à la closure, pas à la fonction englobante. Convertir prématurément tout en Box<dyn Error> fait perdre la possibilité de filtrer par cause. let _ = fallible(); fait taire l'avertissement must-use et jette l'erreur. Mélanger Option et Result dans une même chaîne nécessite ok_or ou transpose.

Quelles erreurs peuvent se contenter d'un From nu

La conversion automatique via From conserve exactement ce que dit l'erreur interne, rien de plus. Cela suffit pour les erreurs qui nomment déjà leur sujet (une erreur d'analyse avec une position, une erreur de client avec l'URL). Cela ne suffit pas pour std::io::Error, qui ne porte ni le chemin ni l'opération, si bien qu'un ? avec From<io::Error> produit 'No such file or directory' sans nommer aucun fichier. Pour ces cas, ajouter le contexte au point d'appel : une variante thiserror telle que #[error("reading {path}")] Io { path: PathBuf, #[source] source: std::io::Error } remplie via map_err, ou, dans du code applicatif, le .with_context(|| format!("reading {}", path.display())) d'anyhow. Règle empirique : un impl From par type d'erreur qui se décrit lui-même ; map_err ou with_context pour chaque appel d'entrée-sortie.