On Tue, 5 Sep 2017 00:11:02 -0700 (PDT) martin.r...@programmfabrik.de wrote:
> - Make it easier to read and follow As a former "inventor" of the "watch construct" I may say that I was wrong. It is NOT easier to read and it is much harder to follow. I was then, as you are now, I was angry about Go's pressure to handle errors right in place so I had to *think* about dealing with errors right here and right now instead of throwing them at someone else (or future-me). Now I value readability of Go most. I - in not mean way - am happy that language itself forced someone to deal with errors *here and now* so I can see what errors I can expect right in block after the call. > - Make it possible to handle errors in one place instead of 10 It is possible now. In Go functions are values. Use tables (or maps), Luke! ;) > BUT my point is, what do I do with 10 or more sql statements, when it > doesn't really matter which one fails why? If I have a thousand of similar checks where I do not care about error details I use something like that: https://play.golang.org/p/ig-KOi92Ku Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
