Code like this:
f, err := os.Open("filename.ext")
if err != nil{
log.Fatal(err)
}
would become:
f := os.Open("filename.ext")
else err != nil {
log.Fatal(err)
}
The `err` variable in the example above is automatically initialized to the last
return value of the function call `os.Open`.
I think this is a bad fit for Go. There's so much magic hidden in the
second version:
* a function which returns N values can now be assigned to N-1 variables
* the Nth value is assigned to a magic variable, whose name is guessed from
the following code block
* the error handling isn't even any shorter - and it definitely is much
less clear
That's without considering the semantic implications. An expression like
"if err != nil", which is a conditional expression, sprouts an automatic
assignment as well. What if there are two variables in the expression,
like "if err != eof" or "if eof != err". Which of these variables gets
magically assigned? You already mentioned that problem towards the end of
your post, and you propose limiting the available expression syntax, so
it's not really a true expression any more. What if you say "if nil !=
err"? But I think the point is that the *reader* of the code shouldn't
have to worry about such things. The code should be obvious from
inspection, and your proposal converts obvious code into non-obvious code.
And unlike throw/catch, you still have to do an explicit error check after
every step.
The explicit error handling in go *can* arguably have the effect of
distracting from the main happy-path logic, but I don't think this is an
improvement.
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/df8bef46-8f36-47cb-958b-4a2ae1355216%40googlegroups.com.
