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/18e49891-9012-433d-89ce-3dfcc0625cedn%40googlegroups.com.
