Proposal: Implicit Error Propagation via `throw` Identifier in Go

Abstract

This proposal introduces a new syntactic convention to Go: the use of the identifier `throw` in variable declarations or assignments (e.g., `result, throw := errorFunc()`). When detected, the compiler will automatically insert a check for a non-nil error and return zero values for all non-error return values along with the error. This mechanism streamlines error handling without compromising Go's hallmark of explicit, readable code.

Motivation

Go encourages explicit error handling, which often results in repetitive boilerplate code. For example:

result, err := errorFunc() if err != nil { return zeroValue, err }

This pattern, while clear, adds verbosity that can hinder readability, especially in functions with multiple error-prone calls. By introducing a syntactic shorthand that preserves clarity, we can reduce boilerplate and improve developer ergonomics.

Proposal

When a variable named `throw` is assigned the result of a function returning an `error`, and the enclosing function returns an `error`, the compiler will implicitly insert:

if throw != nil { return zeroValues..., throw }

Applicable Scenarios

Short declarations:

  x, throw := doSomething()

Standard assignments:

  x, throw = doSomething()

Variable declarations with assignment:

  var x T; var throw error; x, throw = doSomething()

* `throw` must be a variable of type `error`

* The surrounding function must return an `error`

* The rule only applies when the variable is explicitly named `throw`

Example

Traditional Error Handling

func getUserData(id int) (data Data, err error) { data, err := fetch(id) if err != nil { return Data{}, err } return data, nil }

With `throw`

func getUserData(id int) (Data, error) {

    data, throw := fetch(id)
    // Automatically expands to: if throw != nil { return Data{}, throw }

    moreData, throw := fetchMore(id)
    // Automatically expands to: if throw != nil { return Data{}, throw }

    return data, nil
}