Go Programming Experience

Intermediate

Other Languages Experience

Swift, C, C++, JS, Kotlin, Python, Java

Related Idea

• Has this idea, or one like it, been proposed before?
• Does this affect error handling?
• Is this about generics?
• Is this change backward compatible? Breaking the Go 1 compatibility guarantee is a large cost and requires a large benefit

Has this idea, or one like it, been proposed before?

Yes. Similar issues are:

• proposal: spec: handle errors with select #67316, proposal: Error handling: error-specific type switch #70169. Requires errors to be handled in a switch statement. Unclear if there are multiple switch statements per function or just one. Its not clear how multiple errors from calls to multiple functions will be handled. Doesn't seem to reduce existing boilerplate, its unclear how the proposal is different from what we can already do today by using an if/else block. Does not address case when execution must continue after handling error.
• proposal: spec: support new form of switch statement during variable assignment which jumps to function-wide case blocks #65019. Allows case statements in function without surrounding blocks so scoping is very unclear. Allows switch statements to be used as a prefix to variable names, making it confusing when compared with existing switch statements. How to control returning or continuing from error handling is not clear.
• proposal: spec: catch error model, a rethink of check/handle #67859. Quirky syntax but somewhat similar idea. However, variables available in scope of error handling are not clear. Also, handling each error separately is not discussed. Not backwards compatible as all errors cause a jump to a line of code where all error handling begins.
• proposal: spec: check / handle with extra arguments #68720. based on the check/handle proposal. scope of which 'handle' function gets to handle the error is not clear. Returning from 'handle' function confusingly returns from the top-level function. Use of check after each function call that returns an error does not seem to reduce boilerplate significantly.

How this issue is different:

This proposal is backwards compatible, allows handling errors before returning, reduces boilerplate, is clear where each error is handled and the scope of variables available during error handling, provides an explicit declaration that execution continue after error handling if needed, and is easy to read and understand.

Does this affect error handling?

Yes

Related proposals and how this differs:
#43777 - similar to try/catch so unclear if a function returns an error while reading the code. Specific error types has to be known for proper handling from multiple functions. The scope of which handler "catches" what error is not clear.
#56126 - forces return from function without actually handling error. No custom error handling allowed. The magic handleErr function is unclear in what it does. Syntax looks very incompatible with current go syntax.
#62378 - forces return without handling error. Syntax is unclear (hard to read) as well.
#70151 - proposes executing any function returning an error within an error context. Thus, all functions returning errors must be wrapped in 'ctx.Do(...)' call making syntax hard to accept. Also, does not allow continuing after an error occurs and only first error in a series of steps (function calls) can be handled and maybe function must return after that.

Is this about generics?

No

Proposal

Goals of this error handling proposal in order of importance:

• Backwards compatibility with previous golang versions
• Be able to do all the things we are able to do today, for example
  • do something before returning the error
  • choose to continue execution or return after handling error
  • have access to all variables in callee's scope while handling error
• Avoid boiler plate error checking/handling code that exists today
• No steep learning curve, should be easy-to-read and understand

Synopsis:

I am proposing a new statment block called eswitch that handles errors that are returned in the same scope. Errors indicate that they want to be handled by an eswitch block by preceding the error variable name by an @ sign. If an error occurs, control jumps to the respective case statement in the eswitch block. From there, function can return or control can continue after the line where the error occurred. See the eswitch example below.

Code example (contains several scenarios):

func main() {
	// TRADITIONAL WAY
	// usual way to handle errors today
	// this continues to work
	m, err1 := someFunc()
	if err1 != nil {
		// handle err1
		log.Println("error on call to someFunc", err1)
		return
	}

	// NEW PROPOSAL
	// using @<error variable name> implies error will 
	// be handled in the eswitch block closest in scope. 
	// Compiler error occurs if no eswitch block is found.
        // if error occurs, control jumps to the case statement 
        // where this error is being handled in the eswitch block.
        // see `eswitch` block at the end of this function.
	i, @eFunc1 := func1()
	if i < 3 {
		var lvar = 3
		j, @eFunc2 := func2()
		log.Println("result of func2", j)
	}

	// disambiguation with different error name for
	// second call to func1 
	k, @eFunc1CallTwo := func1()

	// block-scoped so can be written in any block. Will handle
	// errors that are returned in the same block-scope.
	eswitch {
	case eFunc1:
                 log.Println("error on 1st call to func1", eFunc1)
		continue  // implies flow continues after first call to func1
	case eFunc2:
		// all variables in scope of where func2 was called should
		// be available here. In this case we should be able to
		// access 'lvar'
		log.Println("locally scoped variable", lvar)
		return // this means return from the function
	case eFunc1CallTwo:
		log.Println("error on 2nd call to func1", eFunc1CallTwo)
		return
	// should we have a default case for
	// all unhandled errors? Is that even
	// benefecial?
	}
}

func func1() (int, error) {
	return 1, errors.New("func1 error")
}

func func2() (int, error) {
	return 2, errors.New("func2 error")
}

func someFunc() (int, error) {
	return 3, errors.New("someFunc error")
}

Is this change backward compatible?

Yes. See above example.