proposal: spec: add "must" operator # to check and return error

[jargv]

The must operator is to error handling what the go keyword is to concurrency, and the defer keyword is to resource cleanup. It turns any function into a Must*-style function with smart error handling.

NOTE: this isn't a change to the way error handling works, only to the way error handling looks.

The Must operator (#) is a unary prefix operator that can be applied to a function call. The last return value of the called function must be of type error. The must operator "peels off" the returned error from the result list, and handles that error - if it is not nil - according to the error handling strategy of the surrounding function.

There are 2 possible error handling strategies:

1. Return zero values, plus the error
2. Panic with the error

The error handling strategy is determined by the surrounding function's return types: if the last return value is of type error, it's error handling strategy is case 1, otherwise it's case 2.

Example:

  result := #foo(1,2,3) 

  // would be equivalent to
  result, err := foo(1,2,3)
  if err != nil {
    return 0, "", person{}, err // if the surrounding function returns an error
  }

  // -- or --

  result, err := foo(1,2,3)
  if err != nil {
    panic(err) //if the surrounding function does not return an error
  }

Some Pros:

1. Error handling works the same way as before, but can be written a bit more tersely
2. A function could very easily change its error handling strategy without changing its contents
3. Adding or removing return values would no longer cascade into code that returns early because of errors. This code very often (always?) returns zero values, plus the error
4. Example code that seeks to be terse would stop using the "drop the error" idiom:

result, _ := canFail() // silent failure!

5. Libraries would no longer have to write "Must*" variants of functions: any function could be called with the Must Operator
6. This is a backwards compatible change
7. This may discourage the use of panic, as an error propagation mechanism
8. Certain kinds of error-heavy code could have a better signal-to-noise ratio, increasing readability:

average := #getTotal() / #getCount()

9. The programmer still has to acknowledge that an error can happen, but can use the Must operator to handle it.

Some Cons:

1. Tools would need to be updated
2. This may seem cryptic to new Gophers
3. This may encouraging more use of panic by hiding the difference between panic and returning an error
4. This may discourage the cases where errors require additional data as they propagate up the call stack:

return fmt.Errorf("while deleting user %s: %v", user, err)
// -- or --
return &CompoundError{"reason", err}

Conclusion

I believe there's precedent for the Must operator in golang. The defer and go keywords transform the way function calls work. The go keyword hides a load of complexity from the user, but always does the right thing. The defer keyword makes code less error-prone by ensuring the cleanup code will be called on every path. The Must operator is similar: it does the right thing based on the surrounding function, and it ensures that the error is handled.

[minux]

You probably want to read the discussion at #16225 first.

[jargv]

Thanks @minux, it's good to get more background. :)

This is different from the try and when keywords proposed because it doesn't imply any kind of data binding or value watching. It avoids many of the issues in those other proposals, IMO.

[bradfitz]

There might be some overlap here with previous proposals, but this is the most comprehensive proposal I've seen about this, and it's actually structured as a proposal, so I'm inclined to keep this open instead of closing it as a dup. Thanks.

[minux]

The reason other proposals are rejected is not because of those fixable drawbacks. The reason is fundamental: the proposed simplification encourages only those two kinds of error handling, but in fact, there is another: augmenting the error before returning to provide more contextual information. (You might say the proposal doesn't preclude the other error handling strategy, but if it makes the first two so much easier to use, it will definitely reduce the incentive for people to even think about using the 3rd.) Anyway, I think it's possible to write a code transformer for this and see what happens.

[jargv]

I agree @minux. That was one of the listed cons. I've thought about this a bit, and while I didn't add this to the proposal (to keep it simple). There could also be a binary form of the operator which calls a function, adding the error to the argument list before returning. Example:

result := UserDeleteError(user)#DeleteUser(user)

// would be equivalent to:

result, err := DeleteUser(user)
if err != nil {
  return UserDeleteError(user, err)
}

// -- or -- (depending on the error handling strategy mentioned above)

result, err := DeleteUser(user)
if err != nil {
  panic(UserDeleteError(user, err))
}

[bradfitz]

@jargv, now you're getting into the ?: ternary operator flow control issue, with code not reading nicely top-down. And now I realize this FAQ entry kinda sucks: https://golang.org/doc/faq#Does_Go_have_a_ternary_form and doesn't provide background on the rationale.

[jargv]

@bradfitz I would love to learn more about that rationale, because lack of ternary is another pain point for me. :) Makes me wonder if I'm missing some of the zeitgeist of Go (though I'm still a big fan!).

Lack of ternary is especially painful when I'm creating nested struct literals and I've got to put a conditional and a variable in order to conditionally populate some field, but now the declaration of the variable and its usage are potentially quit far away, whereas the ternary allows me to elide even creating a variable. Of course, I can change from declaratively creating the struct to imperatively creating it.

Actually come to think of it, declarative struct literals feel a bit like precedent for declarative ternary and declarative error handling. Is it idiomatic to avoid struct literals in go?

[griesemer]

For what it's worth, in the HotSpot JVM we had introduced (almost 20 years ago...) the C++ TRAPS and CHECK macros, trying to address a similar issue using the existing C++ language at that time (and trying to avoid C++ exception handling because compiler performance around functions with exception handling was unclear). The similarity with this proposal (though not notation) is striking. It's interesting to see the same ideas come up again:

Every function that could possibly "raise an exception" (cause an error) ended with the parameter TRAPS in the signature; see e.g., http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/tip/src/share/vm/prims/jvm.cpp, line 116.

Every function call that invoked such a function, ended with a last argument CHECK in the function call (see the same file, line 127).

TRAPS essentially amounted to an extra parameter passed that was used to communicate an error condition. The CHECK macro translated, well, into the following glorious macro...

THREAD); if (HAS_PENDING_EXCEPTION) return       ; (0

(http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/9b0ca45cd756/src/share/vm/utilities/exceptions.hpp, line 183).

I leave it up to the reader to decipher the macros and judge their beauty...

With respect to this proposal, I think it's actually more cryptic than the C++ approach above. Bike shedding aside, # doesn't exactly shout readability. @minux already pointed out other drawbacks. Personally, I'm not a fan for Go (despite my past life involvement with the above).

[mdempsky]

Instead of an operator, it could be a builtin generic function with a signature like:

func must(T1, T2, ..., Tn, error) (T1, T2, ..., Tn)

So calling it just looks like:

result := must(foo(1,2,3))

(Edit: To be clear, I'm not expressing an opinion either way on the overall proposal. I'm just suggesting a less-intrusive syntax to the originally proposed # operator.)

[jargv]

Ha! That's awesome @griesemer, thanks for sharing that. I've done something similar-ish in go (sans macros) to try and invert the error handling responsibility:

func foo1(errp *error, arg1, arg2 int) {
	if *errp != nil {
		return
	}
        // do something useful
}

func foo2(errp *error, arg2, arg2 string) {
	if *errp != nil {
		return
	}
        // signal failure
	*errp = fmt.Errorf("failed because reasons")
}

func main() {
	errp := new(error)
	foo1(errp, 3, 7) 	
        foo2(errp, "3", "7")
        // ...
        // fooN(errp, ...)

        // call N functions for the price of one error handling block!
	if errp != nil {
		log.Printf("*errp: %#v", *errp)
	}
}

[JayNakrani]

Instead of an operator, it could be a builtin generic function

If we're having must as a builtin function, then it could also augment the error. i.e:

func fn() (..., error) {}

a := must(fn(), "extra error info")  // append/prepend string to error returned by fn

b := must(fn(), func(err error) error { /* return the "augmented" error */ })

IMO, this is much more readable than UserDeleteError(user)#DeleteUser(user).

[ucirello]

Having written some examples in the documentation I tend to approach this proposal from the perspective of both using it in examples and impact on new gophers while reading them.

This would become, in my opinion, a very contentious operator/built-in, raising always a flamatory question on whether a such use case is more appropriate using it or not.

Frankly, I do not believe this should be a choice of the developer but of the package. If I, as a developer, must make such call, I can perfectly ending up with a divergent interpretation or decision from a fellow Gopher.

text/template and html/template are nice examples of what I am putting forward. If you happen to have a static template, that by definition shouldn't fail - and it does fail, you can use template.Must to guard against this particular failure. You can preemptively protect from it by running a test using Must and have it again as a return simplifier in the real code.

It is no coincidence we don't see Must functions spread around stdlib. I can imagine few miuses if applied to net or http.

In other words, I think this is a valid idea, but not for the language, only for specific packages that it might make sense.