orelse must return an error (ie satisfies the error interface); the
specific type and variable name do not matter.
although on second thought.. I am not sure that even that restriction is
necessary.
On Sunday, July 30, 2023 at 1:02:04 AM UTC-6 Brian Candler wrote:
Just to be clear: are you hard-coding the variable name "err" into the
semantics of "orelse"? That is, you can't assign the error return to a
variable of any other name?
I disagree that this makes the job of linters any easier than it is today.
For example, if you'd written
...
err = io.Copy(w, r)
err = w.Close() orelse return err
}
then you'd still need to detect "value assigned but not used" in the linter
(assuming it doesn't become *compulsory* to use "orelse" on any assignment
to a variable called "err")
On Sunday, 30 July 2023 at 06:57:15 UTC+1 DrGo wrote:
I looked at the long list of proposals to improve error handling in go but
I have not seen the one I am describing below. If I missed a similar , can
you pls direct me to where I can find it. If not what do you think of this
approach.
This involves introducing a new keyword "orelse" that is a syntactic sugar
for an "if err!=nil" block.
The example code in Russ Cox's paper[1] will look something like this:
func CopyFile(src, dst string) error {
r, err := os.Open(src) orelse return err
defer r.Close()
w, err := os.Create(dst) orelse return err
defer w.Close()
err = io.Copy(w, r) orelse return err
err = w.Close() orelse return err
}
It is an error to not return an error from an orelse block.
In my eyes, this has the same explicitness and flexibility of the current
style but is significantly less verbose. It permits ignoring the error,
returning it as is or wrapping it. Because orelse is not used for any other
purpose, it would be easy for reviewers and linters to spot lack of error
handling.
It also works well with named returns. e.g.,
func returnsObjorErro() (obj Obj, err error) {
obj, err := createObj() orelse return //returns nil and err
}
otherwise orelse is like "else" so e.g., it can be followed by a block if
additional cleanup or error formatting etc is needed before returning, eg
w, err := os.Create(dst) orelse {
....
return err
}
Similarity to "else" hopefully means that it is easy to learn. It is
obviously backward compatible
What do you think?
[1]
https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md
--
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/76530e2e-4d48-4ecc-a232-03626ba85e4an%40googlegroups.com.
