Can we simplify error handling?

[Serhioromano]

$ go version
1.14.1

This is a proposal. I am new to GO and as I understand one of the things about go is a simplification of what is possible to simplify. This Idia become contagious and now this is how I think. When I write GO app very often I return error.

if err != nil {
	return err
}

or if I also return a value

if err != nil {
	return nil, err
}

Could we simplify it to

ereturn err 

or

ereturn nil, err

this is ereturn is error return. It will only return if the last element (which should error) is not nil otherwise bypass. So the could would look like this

fund Test() (int, error) {
    db, err := Connect("localhost:5644")
    ereturn 0, err

    n , err  := db.Get("total")
    ereturn 0, err

    return n, nil
}

Or if we look at last element to be not nil

fund Test() (int, error) {
    ereturn (0) db, err := Connect("localhost:5644")
    ereturn (0) n , err  := db.Get("total")

    return n, nil
}

Where (0) what to return before error in the case the last element which is an error in nil, in our case one int

[andybons]

Thanks for the issue.

We are not considering any changes to error handling at this time.

If you need more context, this has been discussed at length in the past. A Google search for “go error handling proposals” turns up many of these discussions.

[ianlancetaylor]

You can also search the issue tracker at error-handling Language & library change proposals that are about error handling. .

[ianlancetaylor]

See, e.g., #37141.

[Serhioromano]

Thanks for the issue.

We are not considering any changes to error handling at this time.

If you need more context, this has been discussed at length in the past. A Google search for “go error handling proposals” turns up many of these discussions.

I was not considering it to be a change to error handling. The old way can work as usual without a compatibility break. It is just an addition.

[ianlancetaylor]

"Change to error handling" means any change that is expected to affect the way that most code handles errors.

We aren't going to break compatibility in this area. So all changes to error handling will be additions. As I said above, see the issues linked at error-handling Language & library change proposals that are about error handling. for a long list of possible changes (additions) to error handling.