* Dorival Pedroso <pedr...@cpmech.com> [170908 02:08]:
> The "watch" strategy would, of course, allow us to do the important steps
> you've mentioned (e.g. clean up and so on).
>
> For instance:
> watch err != nil {
> // do the important things
> return err
> }
Except that "do the important things" often depends on which step
produced the error. Now you have a switch statement inside the watch
statement to handle the different "early exit" cases. Instead of having
individual "do step1; clean up after step1" in a linear sequence, you
have "do step1; do step2..." with all of the separate "clean up after
stepN" in a switch statement in a different place. You also have
additional code within the "do step1; do step2..." section to allow the
watch statement to determine which switch case to invoke. This is
much easier to get wrong, harder to modify (especially if you have
nested watch statements), and harder to debug.
I believe that the Go devs want to encourage suggestions like yours for
Go 2, but this particular one has already been discussed more than once
on this list. You have numerous experienced programmers who have all
used languages with similar constructs telling you that it looks good at
the start, but ends up producing much less maintainable code. Listen to
experience.
In this particular case, it is not the details that are inconsistent
with the basic philosophy behind the design of the Go language, it is
the entire concept of separating "error" handling from "non-error"
handling. Both are "handling the results" and both belong in the
relative vicinity of the code that produced the results, whether the
results are considered "errors" or "non-errors".
...Marvin
--
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.
