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/330e88d9-8072-4614-ae56-8ce9c59517f3n%40googlegroups.com.
