On Tuesday, September 5, 2017 at 10:39:05 AM UTC+2, Rob 'Commander' Pike
wrote:
>
> If you find that lines like if err != nil are a significant fraction
> of non-test code, your code probably needs a better error handling
> strategy, not a language change. I have done measurements in the past
> and although people complain a lot about the presence of that
> statement, it shows up much less often in practice than people claim,
> and when it does appear a lot it's usually because the programmer is
> not thinking enough about how errors should work.
>
Well, I can try to find more examples, but whenever you interact with say
SQL or other libraries, errors can occur at each call into that library.
Very often it is enough to check the errors for one block (think try...
catch)
The problem with all suggested solutions so far is, that it requires
wrapping function calls of some sort.
Personally, I don't like this. There are calls (say to interact with an SQL
library), and once you start wrapping them in order for an improved error
management, the solution is very local and personal and less readable.
This does not support Go's idea of producing readable code across
developers and styles.
After all the responses in this thread, I thought about my proposal a
little more carefully, so how about this, and it is a construct which can
be used not only for errors:
watch err != nil {
yo1, err = do_stuff1()
yo2, err = do_stuff2()
yo3, err = do_stuff3()
} then {
// handle your error
}
This statement could be used for other cases as well, it is easy to read
and understand, and it saves the programmer from line duplication.
Martin
--
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.
