proposal: Go 2: error handling with error receiver function #36338

drupsys · 2019-12-31T14:43:38Z

Hello everyone,

What if a function that receives only an error could be used as an error receiver for a failed function call?

func errorReceiver(err error) error {
    return fmt.Errorf("some error: %v", err) // do something
}

OK this may be completely crazy also maybe someone already suggested something similar but hear me out...

Overview

// Higher order function that returns an error receiver
func errorHandler(src string) (func(error) error) {
    return func(err error) error {
        return fmt.Errorf("Failed to open file %s: %v", err)
    }
}

func example(src string) error {
    errorReceiver := errorHandler(src)
    r := os.Open(src) or errorReceiver

    // do something with r

    return nil
}

Assume that os.Open fails with an error, since the signature of errorReceiver takes an error as argument the errorReceiver could be called with the os.Open error. Lets see what that would do to the order of execution.

r := os.Open(src) or errorReceiver
os.Open(src) returns nil, fmt.Error("Some error")
call errorReceiver(fmt.Error("Some error"))
If result of errorReceiver is still an error then assign errorReceiver's error to example's return error and exit from example
If result of errorReceiver is nil then continue execution of example

With only one new language concept we are able to reusable handle errors e.g.

func errorHandler(src, dst string) (func(error) error) {
    return func(err error) error {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
}

func CopyFile(src, dst string) (err error) {
    errorReceiver := errorHandler(src, dst)

    r := os.Open(src) or errorReceiver
    defer r.Close()

    w := os.Create(dst) or errorReceiver
    defer func() {
        w.Close()
        if err != nil {
            os.Remove(dst) // only if a “try” fails
        }
    }()

    io.Copy(w, r) or errorReceiver
    w.Close() or errorReceiver

    return nil
}

If in addition to this go was also able to infer the return type of higher order functions then you could end up with pretty clean syntax for error handlers. The above error handler rewritten would look something like.

// The return type of func errorHandler(src, dst string) is implied to be func(error) error
func errorHandler(src, dst string) => func(err error) error {
    return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

Although even without it, this would be a significant improvement.

Handling errors and recovering from them

What if you actually want to handle the error not just simply enrich it? A more sophisticated implementation of error receiver could be implemented. So far all examples of error receiver returned an error, lets go back to my initial example.

func errorHandler(src string) (func(error) error) {
    return func(err error) error {
        return fmt.Errorf("Failed to open file %s: %v", err)
    }
}

What if error receiver here return just the *File, which is the first return value of os.Open, e.g.

func errorReceiver(err error) *File {
    return &File{} // return some default file instead
}

func example(src string) error {
    r := os.Open(src) or errorReceiver

    // do something with r

    return nil
}

Since errorReceiver is no longer returning an error but the expected value of os.Open then the result of errorReceiver could just be assigned to r and the execution of the example could continue, this effectively handles the error.
Note that if os.Open returned more than one non error value e.g. func Open() (T1, T2, ...Tn, error) then error receiver would have to have the following signature func(error) (T1, T2, ...Tn)

More concretely error receiver would have the following valid signatures:

func(error) error - Error receiver that always results in a failure
func(error) T1, T2, ...Tn - Error receiver that always results in recovery
func(error) T1, T2, ...Tn, error - Error receiver that may recover or fail

Final example to show a case where an error receiver itself might recover or fail

func errorHandler(user string) (func(error) error) {
    return func(err error) error {
        return fmt.Errorf("User %s profile could not be found: %v", user, err)
    }
}

func downloadProfileFromAnotherSource(user string) (func(error) (Profile, error)) {
    return func(err error) (Profile, error) {
        profile := serviceB.Find(user) or errorHandler(user)
        return profile, nil
    }
}

func DownloadProfileA(user string) (Profile, error) {
    profile := serviceA.Find(user) or downloadProfileFromAnotherSource(user)
    return profile, nil
}

Conclusion

I think this is a rather neat approach since the only new thing added here is, admittedly, a slightly bizarre behaviour of error receiver when it returns, although the official try(...) error handling proposal was effectively doing the same thing, everything else here is just basic functions. Or am I just having brainfarts? Anyway, I hope someone will find this interesting.

Thanks.

The text was updated successfully, but these errors were encountered:

ianlancetaylor · 2019-12-31T18:18:17Z

If I write code like this

func F(b bool) error {
    errorReceiver := func(err error) error { return err }
    if b {
        f, errorReceiver := os.Open("file")
        // Do something with f
    }
}

I don't understand how we can reliably and simply decide that the assignment to errorReceiver from the call to os.Open should call the existing variable rather than define a new variable of type error.

drupsys · 2019-12-31T18:39:59Z

@ianlancetaylor that is an excellent point, I was really trying to avoid it but I guess the only way for this to work is to have a syntax change that would explicitly state that errorReceiver must be called, something like:

f, ^errorReceiver := os.Open("file") I've used ^ here but I'm not sure what symbol would be appropriate or f, errorReceiver(err) := os.Open("file") or f, call errorReceiver := os.Open("file") or f := os.Open("file"):errorReceiver this one is more like an error capture, syntax here would mean capture error with errorReceiver.

I like the last one a lot personally, so your example would become:

func F(b bool) error {
    errorReceiver := func(err error) error { return err }
    if b {
        f := os.Open("file"):errorReceiver
        // Do something with f
    }
}

Which would resolve the ambiguity of my initial proposal.

drupsys · 2020-01-01T06:05:25Z

P.S. now that I think about it this

func F(b bool) error {
    errorReceiver := func(err error) error { return err }
    if b {
        f := os.Open("file"):errorReceiver
        // Do something with f
    }
}

is just syntactic sugar for

func F(b bool) error {
    errorReceiver := func(err error) error { return err }
    if b {
        f, err := os.Open("file")
        if err != nil {
                if err2 := errorReceiver(err); err2 != nil {
                        return err2
                } 
        }
        // Do something with f
    }
}

icholy · 2020-01-02T21:09:12Z

I looks like using : might prevent using it as an expression for a map literal key.

func key() (string, error) {
    return "key", nil
}

func F(b bool) error {
    errorReceiver := func(err error) error { return err }
    if b {
        m := map[string]bool{
            key():errorReceiver: true,
        }
    }
}

drupsys · 2020-01-02T23:13:45Z

I don't think symbol should be the focus here as we can easily use something else, in fact I don't think I like 1 character symbol at all, since this affects the flow of control it should probably be a keyword:

key() or errorReceiver
key() handle errorReceiver
...

But more importantly are there any fundamental flaws with this approach that I'm not seeing, would this solve majority of issues that people have with the current error handling and most importantly is this go like. These are the questions I don't have answers to.

icholy · 2020-01-03T16:30:09Z

Well then this isn't too different from try then. It was suggested that it could/would be extended with an optional second "receiver" parameter.

func F(b bool) error {
    errorReceiver := func(err error) error { return err }
    f := try(os.Open("file"), errorReceiver)
    // Do something with f
}

drupsys · 2020-01-04T00:32:39Z

TLDR; You should not expect any error handling proposal to be drastically different from try and there is a good reason for it.

I was not aware try proposal had this variant, also if we ever have anything to help with redundant error handling I do not believe it will be massively different from try, at least for as long as we are trying to solve the same problem.

To clarify what I mean, the problem we are all trying to address (as far as I can tell) is highly repetitive error handling, the solution to repetitive code is well known simply factor out code into reusable functions. We should be able to apply the same solution to error handling, I do not see any reason to reinvent the wheel here.

This proposal, try and every other proposal I've read are similar at the core, they are all using some kind of early termination method, more importantly there is no other way to resolve this problem (well... that is not entirely true, there is one other method I can think of... fall-through but I don't think that's a right solution), in other words whatever the solution we chose will involve some kind of early termination and will be largely similar to every other proposal.

If you think about it, this solution, try even more traditional try catch are all just different permutations of the same solution. At its core try proposal was correct, I had some personal issues with the exact implementation, for example I think it is a very bad idea to have a special function that looks like a function but does not behave like a standard function and yes I realise we have panic but just because it was done once doesn't mean it is a good idea.

urandom · 2020-01-06T12:09:21Z

I was not aware try proposal had this variant, also if we ever have anything to help with redundant error handling I do not believe it will be massively different from try, at least for as long as we are trying to solve the same problem.

It wasn't. It appeared in a few comments, but it was never part of the proposal itself. Which is a problem, since one of the biggest criticisms was that you couldn't easily add context to the error (you'd have to use named returns and defers, which added quite a bit of verbosity).

Your proposal, to me, seems to cover 2 of the biggest criticisms of the original try proposal.

With this one, you can easily add context to an error. You can also have helper functions in the stdlib that can make it even easier (e.g.: fmt.ErrorHandler(fmt string, args ...interface{}) func(error) error).

Unlike try, you are not proposing a function, therefore there will be no confusion as to whether this is a function or some sort of control flow. I think this was the biggest mistake of the original try proposal. Whether this proposal goes with a symbol, or (my personal preference) a keyword (or), there can be no confusion as to what the code does. With the proper keyword, a reader might not even need to have knowledge of the language to have an educated guess as to what the construct might do.

ianlancetaylor · 2020-01-28T22:42:40Z

I know that you are not insisting on a particular syntax, but the syntax does matter. One problem with the :handler syntax is that it is obscure. It seem easy to miss the :, and as noted it is confusing when used with composite literals.

Also, it will be very cryptic to a person new to Go. At least try was a clear indication that something was happening, though people would have to learn that it could affect flow control. The : does not have any clear meaning at all (I think).

So I think this needs more attention to syntax.

griesemer · 2020-01-28T22:42:55Z

FYI, here's the discussion of the try version that used an explicit error handler and some of the questions around it: https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md#design-iterations.

ianlancetaylor · 2020-01-28T22:43:19Z

Since this is a language change proposal, could you please fill out the template at https://go.googlesource.com/proposal/+/bd3ac287ccbebb2d12a386f1f1447876dd74b54d/go2-language-changes.md .

When you are done, please reply to the issue with @gopherbot please remove label WaitingForInfo.

Thanks!

guilt · 2020-02-02T00:00:57Z

How about an alternate syntax:

erecv <- f := os.Open(file)

I'd also prefer an inline variant:

{return nil, err} <- f, err := os.Open(file)

drupsys · 2020-02-09T17:41:36Z

@ianlancetaylor

"One problem with the :handler syntax is that it is obscure. It seem easy to miss the :, and as noted it is confusing when used with composite literals" - I agree.

"Also, it will be very cryptic to a person new to Go" - Also agree.

As I was saying : is not a good operator for this, I've come to like or a lot over the last couple of weeks. However, using a word for this operator, a word that has meaning, is making me re-think what the purpose of this operator is.

My original proposal intended the : operator to do two things

one of:

attach context to errors

errorReceiver := func(err error) error { return err }
f := os.Open("file") or errorReceiver
// (file), (err)     or (err)

handle error

errorReceiver := func(err error) *File { return &File{...} }
f := os.Open("file") or errorReceiver
// (file), (err)     or (file)

return from current function if err after handler is executed is still not nil.

these would not terminate current function

errorReceiver := func(err error) error { return nil }
f := os.Open("file") or errorReceiver
// (file), (err)     or (nil)

errorReceiver := func(err error) *File { return &File{...} }
f := os.Open("file") or errorReceiver
// (file), (err)     or (file)

this would terminate current function

errorReceiver := func(err error) error { return err }
f := os.Open("file") or errorReceiver
// (file), (err)     or (err)

The meaning of word or would work great with 1 but or does not imply that the current function will terminate in any way so behaviours of 2 are obscured. I haven't worked through the logic of this fully but I think there are actually two operators hiding here.

Perhaps something like the below is more logically sound:

errorReceiver := func(err error) error { return err }
f, err := os.Open("file") or errorReceiver
handle err

or more concisely:

errorReceiver := func(err error) error { return err }
f := handle (os.Open("file") or errorReceiver)

or operator would implement behaviours described in 1
handle operator would implement behaviours described in 2

Just wanted to give an update as I was away thinking about this for a couple of weeks.

drupsys · 2020-02-09T17:42:40Z

@guilt I kind of agree with others that symbols are not the way to "go" (... I'll walk myself out).

urandom · 2020-02-09T17:58:09Z

@drupsys I personally don't think that the function handler passed to the operator should return any other type other than the one passed in. It should always look like (in a generic syntax):
func (type T)(t T) T { ... }

I would agree that if the handler returns nil, the control should not be terminated. Though any other assignment (in your example the *File) should be zeroed, and the user should then have to initialize that variable in a separate control flow (if file == nil { ... })

guilt · 2020-02-09T18:03:08Z

@drupsys - For me it's less about symbols but more about making error handling concise to relay, where possible.

I'm also all for having it explicitly modeled as a variable (err) than an invisible variable (throw)

steeling · 2021-10-15T00:01:46Z

+1 to the concept in this proposal. One of the biggest improvements over the check/handle proposal is that I can specify which handle I want as opposed to using the closest in scope handle func. That brings in much needed flexibility, especially if I want to alternate between handlers.

I also agree that it'd be beneficial to focus more on the concept, and later on the syntax. Trying to do both simultaneously is likely to be unproductive. If we can agree that this approach is flexible and robust enough, then we can bike-shed on the syntax (just kidding, I know syntax is important) .

Since I"m in agreement with this approach, I'll go ahead and propose a syntax as well :)

func errorHandler(src, dst string) (func(error) error) {
    return func(err error) error {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
}

func CopyFile(src, dst string) (err error) {
    r := check os.Open(src) with errorHandler(src, dst)
    defer r.Close()

    w := check os.Create(dst) with errorHandler(src, dst)
    defer func() {
        w.Close()
        if err != nil {
            os.Remove(dst) // only if a “try” fails
        }
    }()

    check io.Copy(w, r) // not specifying a handler defaults to siply return the err
    err := w.Close()
    check err with errorHandler(src, dst) // you can also check errors directly

    return nil
}

check/with can easily be switched with other keywords. I will mention I do prefer not leveraging a function like try, since parens add more clutter IMO

ofabricio · 2022-04-24T15:13:58Z

I would like you to consider this suggestion.

It basically adds a catch syntax in which the first catch block runs first then a general catch block is called (or jumped) after, with the error. It could also allow passing more arguments, as shown in the original post.

func CopyFile(src, dst string) error {
    r := os.Open(src)   catch
    defer r.Close()
    w := os.Create(dst) catch
    io.Copy(w, r)       catch { w.Close(); os.Remove(dst) }
    w.Close()           catch { os.Remove(dst) }
    return nil
catch (err error):
    return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

gopherbot · 2023-01-26T13:30:36Z

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

gopherbot added this to the Proposal milestone Dec 31, 2019

gopherbot added the Proposal label Dec 31, 2019

ianlancetaylor changed the title ~~Proposal: Error handling with error receiver function~~ proposal: Go 2: error handling with error receiver function Dec 31, 2019

ianlancetaylor added error-handling Language & library change proposals that are about error handling. v2 An incompatible library change LanguageChange Suggested changes to the Go language labels Dec 31, 2019

gopherbot added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Jan 28, 2020

griesemer mentioned this issue Jan 28, 2020

spec: language change review meeting minutes #33892

Open

seankhliao added WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. and removed WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Dec 26, 2022

gopherbot closed this as completed Jan 26, 2023

golang locked and limited conversation to collaborators Jan 26, 2024

gopherbot added the FrozenDueToAge label Jan 26, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

proposal: Go 2: error handling with error receiver function #36338

proposal: Go 2: error handling with error receiver function #36338

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

proposal: Go 2: error handling with error receiver function #36338

proposal: Go 2: error handling with error receiver function #36338

Comments

Uh oh!

Overview

Handling errors and recovering from them

Conclusion

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!