aeris22’s avataraeris22’s Twitter Archive—№ 97,318

                        1. …in reply to @AlainOscarNeo
                          @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…
                          Permalink On twitter.com Twitter logo aeris22’s avatar Mood 0
                      1. …in reply to @aeris22
                        @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.
                        Permalink On twitter.com Twitter logo aeris22’s avatar Mood 0
                    1. …in reply to @aeris22
                      @AlainOscarNeo Ça revient à gzipInput = gzip.NewReader input begin … ensure gzipInput.Close end
                      Permalink On twitter.com Twitter logo aeris22’s avatar Mood +1 🙂
                  1. …in reply to @aeris22
                    @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
                    Permalink On twitter.com Twitter logo aeris22’s avatar Mood 0
                1. …in reply to @aeris22
                  @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
                  Permalink On twitter.com Twitter logo aeris22’s avatar Mood +1 🙂
              1. …in reply to @aeris22
                @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…
                Permalink On twitter.com Twitter logo aeris22’s avatar Mood -1 🙁
            1. …in reply to @aeris22
              @AlainOscarNeo Et ce n’est pas juste une impression… Issu de la code base de go…
              oh my god twitter doesn’t include alt text from images in their API
              Permalink On twitter.com Twitter logo aeris22’s avatar Mood 0
          1. …in reply to @aeris22
            @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)
            Permalink On twitter.com Twitter logo aeris22’s avatar Mood -3 🙁
        1. …in reply to @aeris22
          @AlainOscarNeo Et si on regarde des stats : passe plat powered !!!
          oh my god twitter doesn’t include alt text from images in their API
          Permalink On twitter.com Twitter logo aeris22’s avatar ❤️ 1 Favorite Mood 0
      1. …in reply to @aeris22
        @AlainOscarNeo Sur 11804 « if err != nil », on en a (au moins) 6514 qui sont du bête passe plat, soit 55%.
        Permalink On twitter.com Twitter logo aeris22’s avatar Mood 0
    1. …in reply to @aeris22
      @AlainOscarNeo ie on a pollue le code de plus de 33k de ligne de code pour… du vent…
      Permalink On twitter.com Twitter logo aeris22’s avatar Mood 0
  1. …in reply to @aeris22
    @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.
    On twitter.com Twitter logo aeris22’s avatar Mood -3 🙁