Brian, you pointed out some important issues I was concerned about. Go does
not and should not have any magic, so that is definitely a big problem. I
also agree with you, that limiting the available expression syntax is not
great and that else catch could make code non-obvious.
Regarding doing the explicit error check after every step, I do not mind
doing that and I think it should be done this way. Error handling should be
an essential part of every program and it should not be avoided or tucked
away. It should be explicit and close to the statement it is related to.
As I said in the original post, it is an idea, although it has some quite
big drawbacks/problems. I am really happy with current Go and it is better
it stays the way it is than to add some unnecessary features. Having said
that, it would be nice if we could further simplify error handling,
especially `err != nil` idiom that is repeated many times. Maybe else catch
will help someone think of something better.
Dne nedelja, 16. februar 2020 10.10.29 UTC+1 je oseba Brian Candler
napisala:
>
> 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/780332a6-ed35-4ae5-9dc2-df78205ef475%40googlegroups.com.
