-
@ugobourdon @LupusMichaelis Non justement. Là où go rend OBLIGATOIRE de faire du if err != nil toutes les lignes ou presque, les exceptions ne sont à gérer que là où on sait/doit les gérer…On twitter.com
Mood 0
-
@ugobourdon @LupusMichaelis Sur une erreur d’io par exemple, il est quasiment certain que tu ne sauras pas traiter l’erreur localement dans ta fonction, voire dans la couche modèle, voire dans les services, voire dans les ui.Permalink On twitter.com
Mood +1 🙂
-
@ugobourdon @LupusMichaelis Là où go va te nécessiter au moins une 20aine de ligne de gestion d’erreur dans ta fonction principale, au moins 3 dans les modèle, au moins 3 dans les services et au moins 3 dans l’UI (pour propager l’erreur à chaque fois), les exceptions n’en nécessitent que 3 dans l’ui.Permalink On twitter.com
Mood 0
-
@ugobourdon @LupusMichaelis Exemple à la go : foo err { if err != nil return err } bar err { err = foo(); if err != nil return err } baz err { err = bar(); if err != nil handleError(err) } Exemple à la ruby foo { } bar { foo } baz { baz rescue handleError(e) }Permalink On twitter.com
Mood +2 🙂
-
@ugobourdon @LupusMichaelis Et le problème c’est que la pratique donne tord à go. Sur le top 20 des gestions d’erreur de la codebase go, c’est du passe-plat d’erreur sans traitement possible, et ça représente au moins 54% des cas @aeris22/1306268852741984256Permalink On twitter.com
Mood +2 🙂
-
@ugobourdon @LupusMichaelis Sur hugo, le générateur statique, on en est au moins sur les mêmes volumesPermalink On twitter.com
Mood 0
-
@ugobourdon @LupusMichaelis Partout où tu vois « if err != nil return err » ou équivalent (fatal, panic…), ça veut dire que c’est du code complètement inutile qui n’existerait pas avec une gestion d’exception.Permalink On twitter.com
Mood -6 🙁
-
@ugobourdon @LupusMichaelis La sortie complète, que tu constates par toi-même l’étendu du code « mort » juste pour traiter les erreurs : paste.imirhil.fr/?a9939f4e73931f64#fMnLSIQFGQ9+gwLUIi2h3E0HrjMdvk4/ayGEn/yy9MY=Permalink On twitter.com
Mood 0