-
@AlainOscarNeo Pourquoi être sûr ? Tu sais que ton code peut lancer X et que tu dois le gérer localement, ben tu le gères localement. Et tu arrêtes de polluer ton code pour tous les autres cas qui ne pourront que remonter jusqu’à main…
-
@AlainOscarNeo Ruby est même assez logique sur le sujet et te permet de faire les 2 sans changer beaucoup la logique du code. gzip.NewReader input { |gzipInput| } considère que la stdlib doit gérer elle-même le close & cie et traiter toutes les exceptions en interne.
-
@AlainOscarNeo Ça revient à gzipInput = gzip.NewReader input begin … ensure gzipInput.Close end
-
@AlainOscarNeo Et la version justement instanciée, où c’est toi qui va gérer le bordel, sans la forme block, quand tu veux de la gestion d’erreur spécifique gzipInput = gzip.NewReader input begin … ensure gzipInput.Close doSomethingElse end
-
@AlainOscarNeo Visible par exemple ici : ruby-doc.org/core-2.5.0/File.html#method-c-open File.open 'foo' { } = File.new + ensure https://t.co/YuuBxibKAx 'foo' = https://t.co/Xaq4dIREBd, et tu te démerdes pour gérer le bordel
-
@AlainOscarNeo Et dans 99.99% des cas, tu aurais de toute façon eu à écrire l’équivalent de la forme block dans ton code. Parce que c’est l’écrasante majorité des cas, et l’explication de pourquoi go est rempli de if err != nil { return err }, parce qu’on ne sait pas quoi en faire…
-
@AlainOscarNeo Et ce n’est pas juste une impression… Issu de la code base de go…
-
@AlainOscarNeo Soit c’est du return err ou équivalent, soit c’est du fatal (donc l’équivalent de laisser le truc remonter à main, en moins propre)
-
@AlainOscarNeo Et si on regarde des stats : passe plat powered !!!
-
@AlainOscarNeo Sur 11804 « if err != nil », on en a (au moins) 6514 qui sont du bête passe plat, soit 55%.
-
@AlainOscarNeo ie on a pollue le code de plus de 33k de ligne de code pour… du vent…
-
@AlainOscarNeo Et je pourrais certainement étendre à plus que les 20 plus fréquents, c’est quasiment l’intégralité des cas qui sont des return err ou des fatal ou équivalent, ie du passe plat.
aeris22’s Twitter Archive—№ 97,311
