Une erreur, en Go, n'est pas un événement qui surgit. C'est une valeur qu'on rend.An error, in Go, isn't an event that erupts. It's a value you return.
Le volume 3 s'est clos sur une promesse : error n'est qu'une interface à une méthode, et tout ce qu'on a appris s'y applique. La voici tenue. Là où la plupart des langages traitent l'échec comme une rupture — une exception qui saute par-dessus le code normal et atterrit dans un catch lointain — Go refuse ce canal parallèle. Une fonction qui peut échouer renvoie deux choses : son résultat, et une erreur. L'erreur est une valeur ordinaire, du type error, qu'on teste avec un if, qu'on range dans une variable, qu'on remonte d'un return. Pas de magie, pas de pile qui se déroule en douce. Le contrôle reste dans ta main, visible à chaque ligne.Volume 3 closed on a promise: error is just a one-method interface, and everything we learned applies to it. Here it's kept. Where most languages treat failure as a rupture — an exception leaping over normal code to land in a distant catch — Go refuses that parallel channel. A function that can fail returns two things: its result, and an error. The error is an ordinary value, of type error, tested with an if, stored in a variable, propagated with a return. No magic, no stack quietly unwinding. Control stays in your hand, visible on every line.
// ailleurs : l'erreur saute par-dessus le code normal data := readFile(path) // peut « lever » — rien ici ne le dit parse(data) // … et on l'apprend ailleurs, dans un catch // le chemin d'échec est invisible à l'endroit exact où il naît.
// en Go : l'erreur est un second résultat, rendu là, sous les yeux data, err := os.ReadFile(path) // (.., error) : la signature l'annonce if err != nil { return err // on la propage à la main, explicitement } parse(data) // on n'arrive ici QUE si tout a réussi
Tout ce qui possède une méthode Error() string est une error — la satisfaction implicite du volume 3, appliquée à l'échec. Une erreur est donc une valeur comme une autre : io.EOF est une variable de paquet, qu'on peut comparer avec ==, stocker, passer en argument. Rien de spécial, et c'est tout l'intérêt.Anything with an Error() string method is an error — Volume 3's implicit satisfaction, applied to failure. An error is thus a value like any other: io.EOF is a package variable you can compare with ==, store, pass as an argument. Nothing special, and that's the whole point.
« Une erreur se rend, se teste, se propage — jamais elle ne saute. » Le coût de ce choix est connu : la verbosité, ces trois lignes if err != nil répétées partout. Le numéro défend que ce prix est honnête, et que le seul vrai danger n'est pas d'écrire if err != nil de trop, mais de l'écrire en moins — de jeter l'erreur d'un _ =."An error is returned, tested, propagated — it never leaps." The cost of this choice is well known: verbosity, those three if err != nil lines repeated everywhere. The issue argues that price is honest, and that the only real danger isn't writing one if err != nil too many, but one too few — discarding the error with a _ =.
Les exceptions promettent un code « heureux » débarrassé de la gestion d'erreur — mais elles la cachent, elles ne l'effacent pas. À la lecture, tu ne sais plus quelle ligne peut échouer ni où l'échec sera rattrapé ; le flot de contrôle file en douce vers un catch que tu ne vois pas. Go fait le pari inverse : rendre l'échec visible coûte des lignes, mais on lit le programme tel qu'il s'exécute. C'est le même principe que partout dans le langage — pas de constructeurs cachés, pas de surcharge, pas de magie. L'explicite contre le concis : Go choisit l'explicite, assumé jusqu'à la verbosité.Exceptions promise a 'happy' code freed of error handling — but they hide it, they don't erase it. Reading, you no longer know which line can fail nor where the failure will be caught; control flow slips quietly toward a catch you can't see. Go makes the opposite bet: making failure visible costs lines, but you read the program as it runs. It's the same principle as everywhere in the language — no hidden constructors, no overloading, no magic. Explicit versus concise: Go chooses explicit, owned all the way to verbosity.