proposal: Go 2: builtin: must function

[pjebs]

It would be great if there was a generic must function in "builtin" package.

It would be equivalent to this:

eg. 
Say we have an arbitrary function that looks like this:
x, y, z, err := function()

x, y, z is of arbitrary type T1, T2, T3 respectively.

the proposed must( function() ) function will return x of type T1 if err == nil and panic(err) if err != nil

The function is better suited for functions which return 2 values, the last of which is type error. But it can be generalized to any number of return values provided the final return value is of type error.

[mvdan]

Have you seen https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md? The overlap is significant.

[pjebs]

This proposal is not about error handling (albeit weakly related). The emphasis is syntax sugar and flexibility (eg arbitrary function signatures).

It's about the many occasions when you don't care about the error but just want to use the first result of a function directly in places without creating temporary variables. On other occasions, you do care about the error but want it converted to a panic so you catch it during development (i.e. the error is due to developer error), but during production, you assume no error is possible and you just want to first value directly. The standard library uses the convention MustX(...) in various places for the second scenario.

Due to lack of generics, wrappers are used everywhere in the standard library and people's code due to different data types:

Examples
https://golang.org/src/html/template/template.go#L370 (https://godoc.org/html/template#Must)

This could all be simplified with a generics-compatible builtin "must" function. (NB: builtin already has precedent of generics-compatible functions such as append( ))

Another example where it's useful:

An example from godoc encoding/json.Marshal

type ColorGroup struct {
		ID     int
		Name   string
		Colors []string
	}
	group := ColorGroup{
		ID:     1,
		Name:   "Reds",
		Colors: []string{"Crimson", "Red", "Ruby", "Maroon"},
	}
	b, err := json.Marshal(group)
	if err != nil {
		fmt.Println("error:", err)
	}
	os.Stdout.Write(b)

Sometimes you know that no error is returned because the struct is clearly json-compatible.

It can be simplified to:

type ColorGroup struct {
		ID     int
		Name   string
		Colors []string
	}
	group := ColorGroup{
		ID:     1,
		Name:   "Reds",
		Colors: []string{"Crimson", "Red", "Ruby", "Maroon"},
	}
	os.Stdout.Write(must(json.Marshal(group)))

[pjebs]

The function doesn't even need to be called must. It's just that Go seems to have a convention called Must in some circumstances where this function is useful.

[ianlancetaylor]

CC @griesemer @mpvl

[deanveloper]

I don't think that Go should promote converting errors to panics without first having better ways to handle errors. Errors in Go are well-known to be pretty cumbersome, having an easy way to convert errors into panics would just promote the idea that people shouldn't properly handle their errors.

Now, if one of the several "named handler" counterproposals to the Go 2 Error Handling draft happen, someone could easily just make a handler called must which panics if an error occurs, then call it with something like check@must errorProneFunc()

[pjebs]

@deanveloper This proposal is not about error handling. If anything, this is about ignoring errors.

The conversion of errors to panics is a necessarily consequence of the "inside" function potentially returning an error, yet the "must" function having to return a single value.

Also the conversion to panic has an additional benefit of alerting the developer of developer mistakes during local development. That is currently how it is used in standard package's scenario's such as https://godoc.org/html/template#Must and https://golang.org/pkg/regexp/#MustCompile. That is considered idiomatic go. The proposed function just assists developers write idiomatic go - at least for the scenario the standard package uses it with the MustX pattern.

[pjebs]

@ianlancetaylor why is this a Go2 proposal? Can't it be a Go 1 proposal?

[deanveloper]

@deanveloper This proposal is not about error handling.

Maybe not error handling in the sense of "what should I do with this error to handle it properly" but in the sense of "this function returns an error and I don't want to deal with it, how can I do this easily?"

Also the conversion to panic has an additional benefit of alerting the developer of developer mistakes during local development. That is currently how it is used in standard package's scenario's such as https://godoc.org/html/template#Must and https://golang.org/pkg/regexp/#MustCompile. That is considered idiomatic go. The proposed function just assists developers write idiomatic go - at least for the scenario the standard package uses it with the MustX pattern.

Yes it is idiomatic for that instance, where the code for writing and using templates is already very verbose, and your program would cease to function if the templates were not done properly. The issue with adding a generalized must builtin is that it encourages people to use it to handle errors in an effort to make their own code less verbose.

The issue is that without better error handling, the must builtin will be used as a substitute for lazy developers who don't want to properly handle errors.

Also the reason it's Go2 is because all language changes are being marked as such. More information here

[pjebs]

The issue is that without better error handling, the must builtin will be used as a substitute for lazy developers who don't want to properly handle errors.

I disagree. If such a developer does such an action, then they are writing "incorrect" and bad code by ignoring the error they should not be ignoring. That is not the purpose of must. must is used because you know that no error will be returned - albeit with the additional benefit that a panic will occur during local development due to your own developer errors.

In summary, a good developer would only use the "must" function when either:

1. They know no error is returned (such as my example above) OR
2. The function they are dealing with SHOULD NOT return an error in production but wants additional assistance detecting it during development process (such as how it's currently used in standard package).

[deanveloper]

I disagree. If such a developer does such an action, then they are writing "incorrect" and bad code by ignoring the error they should not be ignoring. That is not the purpose of must. must is used because you know that no error will be returned - albeit with the additional benefit that a panic will occur during local development due to your own developer errors.

I don't think that "that is not the purpose of must" exactly nullifies that lazy developers will use it as a substitute for error handling.

In summary, a good developer would only use the "must" function when either:

Again, a good developer sure, but Go is a simple language with a low learning curve. While good developers may understand how to use must properly, lazy developers won't (or just don't care enough). They won't read documentation as to what may cause certain errors to occur, they write a library, don't properly test it, and get complaints from developers that they wrote lazy code.

The reasons that template and other libraries have Must forms is because they are:

1. Extremely important to the caller that they don't return errors
2. There are large amounts of inputs that will always work properly
3. If the inputs are not proper, it's important that the developer knows

There's a reason that there's nothing like http.MustGet, in many instances, the developer needs to handle a network error properly rather than simply panic if one occurs.