Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Can we simplify error handling? #38349

Closed
Serhioromano opened this issue Apr 10, 2020 · 5 comments
Closed

Can we simplify error handling? #38349

Serhioromano opened this issue Apr 10, 2020 · 5 comments
Labels
error-handling Language & library change proposals that are about error handling. FrozenDueToAge

Comments

@Serhioromano
Copy link

Serhioromano commented Apr 10, 2020 •
edited 

$ 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
Copy link
Member

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 ianlancetaylor added the error-handling Language & library change proposals that are about error handling. label Apr 10, 2020
@ianlancetaylor
Copy link
Contributor

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

@ianlancetaylor
Copy link
Contributor

See, e.g., #37141.

@Serhioromano
Copy link
Author

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
Copy link
Contributor

"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.

@golang golang locked and limited conversation to collaborators Apr 13, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
error-handling Language & library change proposals that are about error handling. FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@andybons @Serhioromano @ianlancetaylor @gopherbot