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.

@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.

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
    }
}

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,
        }
    }
}

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.

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
}

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.

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.

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.

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.

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!

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)  

@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

1. 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)

2. 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.

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

@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 { ... })

@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)

+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

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)
}

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.)