Proposal: A built-in go error check function, "catch"

[natefinch]

This is a counter-proposal to #32437

Proposal: A built-in Go error check function, catch

catch would function much like the proposed try with a few specific differences:

1.) catch would not return any values, meaning it must be on a line by itself, like panic()
2.) catch takes 1..N arguments
2a.) the first argument must be of type error
2b.) The remainder of the arguments are optional and wrap the error using the given format string and args, as if sent through the new fmt.Errorf which does error wrapping similar to github.com/pkg/errors.

e.g.

func getConfig(config string) (*Config, error)
    f, err := os.Open(config)
    catch(err)
    defer f.Close()
    // use f to make a c *Config...
    return c, nil
}

In this code, catch is the equivalent of

if err != nil {
    return nil, err
}

If err is non-nil, it will return zero values for all other return values, just like try. The difference being that since catch doesn't return values, you can't "hide" it on the right hand side. You also can't nest catch inside another function, and the only function you can nest inside of catch is one that just returns an error. This is to ensure readability of the code.

This makes catch just as easy to see in the flow of the code as if err != nil is now. It means you can't magically exit from a function in the middle of a line if something fails. It removes nesting of functions which is otherwise usually rare and discouraged in go code, for readability reasons.

This almost makes catch like a keyword, except it's backwards compatible with existing code in case someone already has the name catch defined in their code (though I think others have done homework saying try and catch are both rarely used names in Go code).

Optionally, you can add more data to an error in the same line as catch:

func getConfig(user, config string) (*Config, error)
    f, err := os.Open(config)
    catch(err, "can't open config for user %s", user)
    defer f.Close()
    // use f to make a c * Config...
    return c, nil
}

In this configuration, catch is equivalent to

if err != nil {
    return nil, fmt.Errorf("can't open config for user %s: %v", user, err)
}

And would utilize the new implicit error wrapping.

This proposal accomplishes 3 things:

1.) It reduces if err != nil boilerplate
2.) It maintains current legibility of exit points of a function having to be indicated by the first word on the line
3.) It makes it easier to annotate errors than either if err != nil or the try proposal.

[natefinch]

For the record, I don't mind if err != nil, and all things being equal, I would rather not remove that boilerplate, since errors are just values and all that jazz. I know many, many long-time gophers that agree.

However, if we're going to change the language, this is a much better change than the proposed try in my opinion. This maintains legibility of code, maintains ease of finding exit points in the code, still reduces boilerplate, and encourages people to add context to an error.

IMO it removes the major faults of try, which are the high likelihood of missing a call to try embedded in the right hand side somewhere when reading code, and the problem of encouraging nesting of functions which is distinctly bad for code readability.

[thepudds]

One variation would be:

• to start, catch only takes one argument
• don't allow catch to take additional arguments for format string and args
• after experience or experimentation, consider including a handler function as an optional second argument, such as:

  decorate := func(err error) error { return fmt.Errorf("foo failed: %v", err) }

  ...

  f, err := os.Open(config)
  catch(err, decorate)          // decorate called in error case

or using helper functions that could live somewhere in the standard library:

  catch(err, fmt.Annotatef("foo failed for %v", arg1))      

That would be more parallel to the current proposal for try as a builtin.

edit: part of the rationale for a handler function is it means a builtin does not directly rely on fmt semantics, which is the concern @Merovius expressed better in the next comment.

[Merovius]

My main reason for disagreeing with that is that it couples the fmt-package into the language. i.e. to actually add this to the spec, you'd also need to define what fmt does in the spec - and IMO, fmt is far too large (conceptually) to be part of the language proper. So, IMO, the multiple-argument form you are suggesting should be removed.

[natefinch]

That's a good point, and actually why I made 2a and 2b. I think we could remove 2b pretty easily. It could easily be replaced by a helper function in fmt (or user code):

// Wrap returns nil if err is nil, otherwise it returns a wrapped 
// version of err with the given fmt string as per fmt.Errorf.
func Wrap(err error, msg string, args ...interface{})

then you could do

catch(fmt.Wrap(err, "error opening config for user %s", user))

It's not quite as nice, though.

And for the record, I'd be ok with making this part of fmt be part of the language if it encourages people annotate their errors.

[rof20004]

@natefinch What about if i have more than two returns?

func getConfig(user, config string) (*Config, error, result)
    f, err := os.Open(config)
    catch(err)
    defer f.Close()
    // use f to make a c * Config...
    return c, nil, nil
}

[natefinch]

It works like try from the linked issue, where using it requires that it's in a function where the last return value is of type error, and it returns zero values for everything except the error.

so like if you had

func getConfig(user, config string) (*Config, result, error)

catch(err) would return nil, result{}, err

[bakul]

You can simplify this a bit. Since it expects an error value, you can give it any error value. So then it can be catch err or catch fmt.Errorf(“can’t open config for %s”, user) — no need to implicitly use this error generating function and you can return any kind of error that makes sense in your situation. Though I don’t like the use of catch. It would be perfectly legal in your scheme to say something like this but it looks weird!

    If !inrange(low, value, high) {
        catch OutOfRangeError
    }

Except for the name, this would be a perfectly legitimate use at the where error conditions are first detected and even better than having to say

    If !inrange(low, value, high) {
        return nil, OutOfRangeError
    }

On IBM systems on can use a macro ABEND to abnormally terminate a task. It was a bit like panic but the name was suggestive of its intended use. catch doesn’t have that. Neither did try. I thought of returnOnError or errorReturn or just ereturn or abreturn or may be even raise as in C. Any of these work for me better than catch or try but none seem ideal.

[natefinch]

So, it can't be a keyword, because that's not backwards compatible. So it would need to be catch(OutOfRangeError) ....

I do agree that the name might need some tweaking. Naming is hard, and I welcome suggestions for another name that might be more appropriate.

The problem is really that it is most accurately called maybeReturn

How about yield? Where it's keep going, or stop if something is in the way? Also yield is to produce, like it produces the error.

f, err := os.Open(config)
yield(err) 
defer f.Close()

and then it could be

yield(OutOfRangeError)

which looks better to me

[bakul]

(Ignoring its use as giving up the processor to another coroutine or thread) yield is better than catch!
returnOnError or returnIfError exactly captures the semantics but it is a bit long.

returnIf can also work provided error values have err or error in their name.

returnIf(OutOfRangeError)

[provPaulBrousseau]

Both yield and catch have very strong connotations in other languages, and I wouldn't suggest them for your proposal. As you say, naming is hard.

But I have to disagree with this if for no other reason than its rigidity; if

catch(err, "can't open config for user %s", user)

is really just

if err != nil {
  return fmt.Errorf("can't open config for user %s: %v", user, err)
}

... it's really not that valuable. Most of my error handling is done with github.com/pkg/errors, although I have yet to evaluate the new proposals around wrapped errors. And others perhaps like dedicated typed errors, while others may use constants. This solves a narrow set circumstances.

But to think this through further... what happens in this case:

func DoYourThing(a string) (x string, err error) {
  x = fmt.Sprintf("My thing is '%a'", a)
  // always returns an err
  err = DoSomethingBad() 
  catch(err)

  // process some other stuff.

  return
}

func DoAThing() {
  x, _ := DoYourThing("cooking")
  fmt.Printf("%s!!\n", x)
}

[bakul]

@provPaulBrousseau, IMHO catch or its equivalent shouldn’t be used if you are returning an error as well as a legit value. [This is another reason I bemoan the lack of a sum type in Go. With sum type you’d use it in most cases where an error or a legit value is returned but not both. For examples such as yours, a tuple or a product type would be used. In such a language catch would only work if the parent function returned a sum type]

But if you do use catch, it would return “”, err.