11–20 of 245 posts
I'll agree that this is perhaps the single thing that I don't like about Go. Now, you can argue it helps with "explicit error handling" and all that, but in that case you might as well have must-be-caught exceptions. Anyone want to fork Go?
Errors aren't the same things as exceptions.
I'll agree that this is perhaps the single thing that I don't like about Go. Now, you can argue it helps with "explicit error handling" and all that, but in that case you might as well have must-be-caught exceptions. Anyone want to fork Go?
What is it about panic/recover that forking the language , not merely using Go in a non-idiomatic way, would be necessary? I could see forking it to add generics in a way that the official guys aren't satisfied with, but why is that needed to use another style of error handling?
This is Go's mechanism for handling (or ignoring errors) which imho is really nice because you don't have to learn anything extra, like throwing/catching error mechanisms
Earlier quoted context omitted.
What is it about panic/recover that forking the language , not merely using Go in a non-idiomatic way, would be necessary? I could see forking it to add generics in a way that the official guys aren't satisfied with, but why is that needed to use another style of error handling?
Because all of the rest of the ecosystem uses a different way, and switching between two different styles isn't fun.
Are we talking about just forking its standard library and not actually changing the language?
Once again the president has been saved, thanks to HTTP Pedantry.
I suppose it's all a matter of taste. The error handling design decision is one thing I really like about Go. I write high reliability embedded software and "throw/catch" just doesn't cut it for me since it obscures possible error conditions thrown from subroutines. I want to have to explicitly deal with those errors whenever they might occur and error returns are a good way of doing that. For every language feature…
The author of the blog post is overlooking a major feature here. Go does multiple return types, so you can do things like this: i, err := getValue() however if you want to ignore a return variable or in this case the returned error you use an underscore like this (same as in haskell): i, _ := getValue() This is Go's mechanism for handling (or ignoring errors) which imho is really nice because you don't have to learn…
If you were to handle the same error cases in Python that you gave examples for in Go, it would probably be even more verbose with the try/catch wrapped around.
> Errors passing silently – ticking time bombs to go
Are you kidding? Unless exceptions are documented well, which they rarely are, this is a much greater problem when using exceptions.
Maybe a better error handling mechanism is needed - but I'd prefer if it's not exception handling. Perhaps lisp style error handling? What ever that is - for I'm not familiar with it - but I keep hearing lispers brag about how awesome it is!