-
@ugobourdon @LupusMichaelis Oui, ça se compose justement très bien… À la go, horrible foo { err = bar(); if err return err err = baz(); if err return err err = quz(); if err return err } À la ruby, net et sans bavure foo { bar; baz; quz }Permalink On twitter.com
Mood -3 🙁
-
@ugobourdon @LupusMichaelis La version go rend aussi complexe la gestion de l’erreur le cran au dessus comment puis-je faire foo { bar; baz; quz rescue Bar1Exception handleError1 rescue Baz2Exception handleError2 } en go ? Sauf à m’emmerder à faire du wrapping d’erreur partout pour sous-typer…Permalink On twitter.com
Mood +4 🙂
-
@ugobourdon @LupusMichaelis En effet go se limite par défaut à remonter une « error » non sous-typée sinon à aller se taper du if sur le message d’erreur… 😑 Il faudrait donc wrapper toutes les erreurs de chaque méthode dans une sous-classe précise pour pouvoir ensuite décider de quoi et comment traiter…Permalink On twitter.com
Mood -2 🙁
-
@ugobourdon @LupusMichaelis Bref, tu passes ta vie à gérer des erreurs que tu ne sais pas gérer et donc à faire du passe-plat de couche en couche, avec 3-5 lignes de gestions d’erreur toutes les lignes de code métier… Et ça complexifie aussi le code avec un facteur de branche explosif…Permalink On twitter.com
Mood 0
-
@ugobourdon @LupusMichaelis Oui, parce qu’en ruby je ne vais justement pas à avoir à tester tous les cas d’erreur, je suppose que **le langage** fait son taff avec les exception. En go, je dois a minima unit-tester **mon** code de « if err return err » pour s’assurer que je ne l’ai pas oublié…On twitter.com
Mood 0
-
@ugobourdon @LupusMichaelis En go : foo { err := bar if err != nil return err } nécessite 2 tests U : le cas nominal qui doit retourner nil et le cas d’erreur qui doit retourner pas nil. Pour détecter une bourde du type foo { err := bar if err != nil return nil } En Ruby foo { bar } ne nécessite qu’un testPermalink On twitter.com
Mood 0