On Mon, Oct 29, 2018 at 8:26 PM DrGo <salah.mah...@gmail.com> wrote: >
> > As many have pointed out, the check keyword has several shortcomings the most > important for me are that: > (1) it obscures the change in workflow and (2) it treats error values > differently than all other values. > > Overall, I do not think that the gain in brevity compensates for the loss in > code clarity (and for the addition of 2 new keywords). Perhaps I am lacking > in imagination, but I am finding it really hard to think of ways to beat the > exquisite balancing act that Go 1 achieves when it comes to handling errors > and exceptions. > > What do you think? I agree that the brevity suggested by the official proposal obscures the code. There are some counter-proposals that suggest similar ideas: https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback > > -- > 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. -- 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.
