proposal: Go 2: orelse for streamlined error handling

[DrGo]

as per @ianlancetaylor: "Please let's not have a discussion about error handling in general on this issue. Please only discuss this specific proposal. Thanks."

This proposal is not about avoiding typing few keystrokes or shirking responsibilities for error handling or about making error handling in Go like any other language. It simply aims to use the compiler to reduce the mental workload of reading/reviewing error-heavy code. Error handling with this approach will remain as explicit and as boring as ever!

Author background

• Medical doctor/Professor who has been using Go since 2013 in several projects, and has experience with several other languages (c, Pascal, Javascript).

Proposal

I propose a new keyword orelse that is:

• legal only, but not mandatory, following an assignment to a variable that satisfies the error interface, and
• triggers the execution of an error-handling code block when the error variable is not nil. Other than being automatically triggered, there is nothing new or special about the triggered block.

Example

The example code in Russ Cox's paper[1] will look like this:

func CopyFile(src, dst string) error {
	//one line orelse 
	r, err := os.Open(src) orelse return fmt.Errorf("copy %s %s: %v", src, dst, err)
	defer r.Close()
	
	// orelse does not open a new scope
	w, err := os.Create(dst) orelse return fmt.Errorf("copy %s %s: %v", src, dst, err)
	
	// multi-line orelse block
	err := io.Copy(w, r) orelse {
		w.Close()
		os.Remove(dst)
		return fmt.Errorf("copy %s %s: %v", src, dst, err)
	}

	err := w.Close() orelse  {
		os.Remove(dst)
		return fmt.Errorf("copy %s %s: %v", src, dst, err)
	}
}

Rationale

The verbosity of Go's standard error handling approach is now a top concern for Go developers responding to the last annual survey. A more ergonomic approach should encourage adopting best practices of error handling and make code easier to read and maintain.

Compared to the current approach, I believe the proposed approach is:

• significantly less verbose, e.g., the ratio of error-handling to program logic lines in the above program is 5:5 compared to 13:5 in the original sample,
• as explicit; both the error-handling code and the potential for change in program flow are at least as clear,
• no less flexible since it permits ignoring the error, returning it as is or wrapping it.

Because orelse is not used for any other purpose, it would be easy for reviewers and linters to spot lack of error handling. And because it is semantically similar to an else block, it should be easy to learn and understand.

Additional advantages include:

• it builds on recent improvements in the standard errors package such as wrapping and unwrapping errors, e.g.,

_, err := io.ReadAll(r) orelse return errors.Wrap(err, "read failed")

• it works well with named/bare returns, e.g.,

func returnObjOrErr() (obj Obj, err error) {
  obj, err := createObj() orelse return  //returns nil and err
}	

• orelse does not open a new scope when it is not desired making it more ergonomic and reducing the risk for variable shadowing as in this example of a widely used idiom:

	if w, err:= os.Create(dst); err!= nil {} // new scope is opened preventing 
            // subsequent use of w and possibly shadowing a func-level err variable. 

• it is still "Go-like"; each error is still handled individually although it should be easier to call a closure or a method to further deduplicate error handling. In this sense, it is similar to the try/handle approach without requiring an extra new keyword or inserting try in the middle of expressions.

func CopyFile(src, dst string) error {
    copyErr:= func(err error) {
		// do other stuff: log the error, set flags,
              //  format a nice error message etc
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }   
    r, err := os.Open(src) orelse return copyErr(err) 
  
    w, err := os.Create(dst);  orelse return copyErr(err)
    
   ... etc
}

• it is backward compatible and does not prohibit those who prefer to use the current approach from continuing to use it.

• it can handle the very rare situation when a function returns more than one error. The oresle block is invoked if any error is not nil.

Costs and risks

• one extra keyword, although a familiar one and most previous proposals introduce at least one keyword or punctuation.
• some proponents of the current approach may fear that it might encourage not handling errors. Whereas it is hard to be certain, I do suspect that having an ergonomic approach and a keyword dedicated to error handling will encourage proper error handling and make it easy to include correct examples of it in tutorials and code samples instead of skipping it as is often the case currently.
• I do not foresee a significant impact on compile or runtime performance.

[1] https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md

[gophun]

I'm not arguing for or against this proposal, but it could simply use 'else' instead of introducing a new keyword. It should be unambiguous to parse in that position.

[seankhliao]

Besides the slightly different syntax, what makes this sufficiently distinct from previous proposals like #41908 #56895

[DrGo]

Besides the slightly different syntax, what makes this sufficiently distinct from previous proposals like #41908 #56895

Thanks. I did not see the latter proposal despite searching the wiki entry on error handling..However, in my proposal I am focused on addressing the cultural issues that blocked progress on solving this problem. Also orelse is meant to be different from `else' to avoid giving the impression that it can be used anywhere where a returned value is not nil. This is specifically an error-handling mechanism.

[ianlancetaylor]

Also looks similar to #32848 and #32946.

[DrGo]

The solution space is very restricted... so it is not surprising that there will be similarities to previous proposals. The important thing here in my view is that we are having a discussion about an issue that is important to many Go users. Although I suspect that a vocal minority has already decided that the more verbose error handling the better, and that Go will die a slow painful death if another option was to be introduced!

[gophun]

Although I suspect that a vocal minority has already decided that the more verbose error handling the better

It could also be that those who are unsatisfied with the current error handling are a vocal minority.

[ianlancetaylor]

I agree that it is worth discussing. The place to discuss it is golang-nuts, and there is already an active discussion there. GitHub issues turn out to be bad at handling generalized discussions, because they are not threaded and when there are lots of comments they start hiding some. So if you want to discuss error handling, please do, but not here. Keep the issue tracker for specific proposals. Thanks.

[DrGo]

No.. we have evidence from several surveys that it is a significant number of people. The important thing here is that the changes proposed do not affect those who prefer to use the current approach.. it does not complicate the language (in fact it simplifies error handling and learning and teaching it) and it does not affect compiling or runtime performance so it is hard to see why the resistance.

[DrGo]

I agree that it is worth discussing. The place to discuss it is golang-nuts, and there is already an active discussion there. GitHub issues turn out to be bad at handling generalized discussions, because they are not threaded and when there are lots of comments they start hiding some. So if you want to discuss error handling, please do, but not here. Keep the issue tracker for specific proposals. Thanks.

I started that discussion on this particular proposal and overall the debate was encouraging so I proceeded to put a formal proposal.. I do not mean for this to be just a discussion. I think this is an appropriate time to resurface such a proposal after all the more urgent issues, e.g., modules and generics, were addressed. To me the obstacle to addressing this issue has been mostly cultural. I am hoping that the many recent changes in Go may have blunted the sharp divide between the error-handling camps so that we can find a compromise solution that works for all. Thanks

[gophun]

No.. we have evidence from several surveys that it is a significant number of people.

The surveys indicate a significant number, but do not confirm whether it constitutes a majority. What we know is that no single error handling proposal has garnered a majority of support so far.

it does not complicate the language (in fact it simplifies error handling and learning and teaching it)

Introducing more ways of doing the same adds complexity to a language.