Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Proposal: go2 - Expand check functionality with scoped handle blocks #33002
Based on the current proposals and counter proposals I would propose a revision of the
My proposal is to add the option to have fully scoped blocks as well as requiring the handle to scoped, and enforce the variable assignment already used in golang. Finally the handle would move to the bottom, to maintain the logic of top to bottom programming logic (which the original check/handle breaks).
A simple example could be the following:
Alternatively you can also write the following:
There can be a discussion about omitting the handle part which would automatically translate to the following:
If we take a look at a common used example below:
This can now be rewritten as such:
or alternatively, depending on your preference:
or a mix of oldskool + proposal:
This makes generic error handling (non-lazy as opposed to:
As such the requirements are the following:
The goal is to make the codebase repeat itself less while maintaining a clear flow of function handling, while giving the developers the possibility to handle the errors in whichever way they want.
Discuss away, if you vote, please leave a reasoning as to why.
It can be seen as such, however it also allows for just adding the check keyword to multiple functions and handling them in a similar way.
Finally, I do prefer the scoping of a try / catch in other languages, as it is clear what is happening.
When using a
The idea would be that a check block would be a scope where all the functions are checked.
Otherwise all normal operations are allowed, however, to stay consistent with the golang spec, everything declared within the
I added more functions in the initial examples (first 2) to showcase how functions would be handled.
That does suggest that adding an error result to an existing function will cause a silent behavior change. If the
Would you suggest to require that all functions in a check block send an error at the end?
Alternatively we can suggest that every function inside a check block still requires the
Good catch on the silent behavior.
My main concern with this is that it disrupts the ability of happy path not being indented. Currently, if you don't use else understanding a function's happy path just means ignoring all indented code.
My other concern is having multiple statements in one check block. Some developers would probably put the entirety of a function within a check block. That would make the code look simpler but changes the philosophy of dealing with errors when they happen, which is my favorite part of go. It makes my code feel safe.