Now that the try proposal (#32437) has been withdrawn, I have been thinking about whether there might be a middle-ground proposal which would still save significant error handling boilerplate but be more acceptable to those who disliked try.

After studying various alternative proposals and the factors which led to try's demise, I have come up with the following which is even simpler and might fit the bill. There have been many similar ideas (notably #32811 which was a major influence) though probably not in the exact form used here.

The proposal.

I propose the introduction of a new built-in function called check. This takes a single parameter of a particular interface type (usually error) and does not return anything.

check can only be used inside a function with at least one result parameter where the last result is of the same interface type.

If the argument to check is nil, then it does nothing and control passes to the next statement.

However, if the argument is not nil, then it triggers an immediate return from the enclosing function. The final return parameter of the function is set to the argument to check and any other return parameters are given their zero values (or current values if named).

So, this:

check(err)

turns into the following inlined code:

if err != nil {
    return x1, x2, ...xn, err 
}

where the x's are the zero values (or current values) of any other return parameters apart from the final interface parameter.

Aim of the proposal

The aim of this proposal is exactly the same as try, namely to cut down on boilerplate in a significant number of cases.

As in the case of try, all errors can be decorated in the same way using defer or the current if err != nil approach can and should be used in all other cases.

As a new built-in function is being used, it would still be backwards-compatible and would still be open to possible future improvements by simply adding a further parameter or parameters to check.

Example

The following example taken from the try proposal may help to make all this clear:

func CopyFile(src, dst string) (err error) {
    defer func() {
        if err != nil {
             err = fmt.Errorf("copy %s %s: %v", src, dst, err)
        } 
    }()

    r, err := os.Open(src)
    check(err)
    defer r.Close()

    w, err := os.Create(dst)
    check(err)
    defer func() {
        w.Close()
        if err != nil {
            os.Remove(dst) // only if "check" fails
        }
    }()

    _, err = io.Copy(w, r)
    check(err)

    check(w.Close())
    return nil
}

Note that a function which only returns an interface value of the relevant type (such as w.Close()) can be passed directly to check().

Advantages

Compared to the try proposal, the present one has the following advantages:

1. It's simpler and should therefore be easier to implement, understand and document.

2. Custom error interfaces can now be coped with - though I believe try could have been altered to do the same.

3. It will be easier in most cases to refactor between code using check and the present approach, which should make debugging easier. Also the former doesn't look out of place where both approaches are used in the same function.

4. The word check is perhaps more suggestive that a change in flow control may be triggered than try was.

5. As check doesn't return anything, this effectively rules out the possibility of there being several independent errors on the same line (i.e. try expressions, nested or otherwise) which a lot of people disliked (albeit others saw as an advantage).

Disadvantages

Compared to the try proposal, the present one has the following disadvantages:

1. It doesn't save as much boilerplate.

2. check is probably used more than try as an identifier in existing code and is longer.

Finally

I should perhaps add that I'm not totally sold on this proposal (or for that matter any other alternative proposal) myself as it's questionable whether it saves enough boilerplate to be worth doing but it certainly looks more compact.

Incidentally, I've given up hope that go fmt will be changed to permit single statement if's to be written on one line which would have made even the present approach look more compact.

Also this proposal doesn't address (or even attempt to address) the problem of error decoration any better than try did because, quite frankly, I think this is best done with the existing if err != nil approach unless all errors can be decorated in the same way when defer can be used.

However, I think it's arguably clearer what's happening with this proposal and so I thought that I should at least put it forward to see whether there's any support for it. If not, then it's something else we can rule out once and for all.