It states " The check / handle combination is permitted in functions that do not themselves return errors.", but the very first example there (as well as more examples in the full draft design doc) feature a function that returns an error (CopyFile()). What am I missing/misreading?
Edit: I clearly haven’t had enough sleep It means the combination can be used in even functions that do not return errors as well as those that do.
Anyway, I’m pretty excited about the error handling proposal; it seems like it will make things less much verbose in general while still encouraging proper handling of errors.
Will it make things less verbose ? I hope so, but I do not think it will be by much. For each error you still need to do something specific about it.
More than that, it will make syntax different than C/Java/Python - therefore a little bit harder to learn, therefore less young people will take up Go.
Also, it solves what problem ? Did anyone complain that Go is too verbose due to error handling - I don’t think so.
I am sure the proponents see the benefits in this, I do have however a little bit of doubt.
Did anyone complain that Go is too verbose due to error handling - I don’t think so.
Yes, I’ve seen people complain about error handling and suggest ways to improve it many times. It seems they have as well, they list some of these cases on the draft design page for reference (see “Background” sections, where they say “There have been many proposals over time to improve error handling in Go”: Error Handling — Draft Design )
Don’t get me wrong - I like Go’s error handling currently, but I do see room for improvement. This draft design proposes some improvements that I would appreciate. The nice thing is that the error handling features should be entirely backwards compatible, so nobody is forced to use them (at least not by the language itself)
One of the strengths of Go is that it (used to) change rarely and only for a good reason. If it gets changes (additions) every year, just like Java does, it will push people away from it.
I understand that with Java (only an example, most others are not better) there is a department in a corporation, in this department must report its activity every year, that is why there is extra incentive for new changes every year.
Go should not fall into this trap.
Also, there is another problem Go faces: the changes and decisions should be public and democratic. Not an elite group deciding its future, but a broad large community using its collective reasoning and serving its collective needs - should decide any changes.
This is why I believe it is important that for any new feature there should be a really big need and a really big crowd to actively demand it.
I think we are largely in agreement. My perception here is that error handling (like generics) has received enough attention in terms of potential improvements that the team decided now there may be a good reason to do this. From what I understand the publication of these drafts is intended to be exactly what you suggest: making the discussion public and seeking feedback on the proposals from the interested community. These drafts aren’t mandates or feature announcements.
it is also VERY important to note that these changes are for Go 2, and while they have stated that they want to keep as much backwards compatibility as possible moving to v2, it has also been stated that v1->v2 is where any large or compatibility breaking changes will go.
It means the combination can be used in even functions that do not return errors as well as those that do.