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.

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

proposal: "reflow" keyword for error handling #21146

Closed
sebtzm opened this issue Jul 24, 2017 · 4 comments
Closed

proposal: "reflow" keyword for error handling #21146

sebtzm opened this issue Jul 24, 2017 · 4 comments
Labels
error-handling Language & library change proposals that are about error handling. FrozenDueToAge LanguageChange Proposal v2 A language change or incompatible library change
Milestone

Comments

@sebtzm
Copy link

sebtzm commented Jul 24, 2017

I would like to propose a new keyword "reflow".
This keyword acts as "return" only if the last value to return is not nil, otherwise it does nothing and execution of function goes on.
It can be very helpful to return values along with an error without having to write an if statement to check that the error is not nil every time.

It replaces a function like this:

func MyFunction() (data string, err error) {
	if data, err = doSomething(); err != nil {
		return data, err
	}
	
	...
	
	doAnotherThing(data)
	return data, nil
}

in a more concise way:

func MyFunction() (data string, err error) {
	data, err = doSomething()
	reflow data, err
	
	...
	
	doAnotherThing(data)
	return data, nil
}

Practically, the reflow keyword returns from function only if the last argument is not nil.

@gopherbot gopherbot added this to the Proposal milestone Jul 24, 2017
@ianlancetaylor ianlancetaylor added the v2 A language change or incompatible library change label Jul 25, 2017
@ianlancetaylor ianlancetaylor changed the title Proposal: "reflow" keyword proposal: "reflow" keyword Jul 25, 2017
@ianlancetaylor ianlancetaylor changed the title proposal: "reflow" keyword proposal: "reflow" keyword for error handling Jul 25, 2017
@ofabricio
Copy link

ofabricio commented Nov 19, 2017

How about something like this:

func MyFunction() (string, error) {
    data, err := doSomething() return nil, err
    
    ...
    
    doAnotherThing(data)
    return data, nil
}

Another example:

func ReadFile(path string) ([]byte, error) {
    f, err := os.Open(path)
    if err != nil {
        return nil, errors.Wrap(err, "open failed")
    } 
    defer f.Close()

    buf, err := ioutil.ReadAll(f)
    if err != nil {
        return nil, errors.Wrap(err, "read failed")
    }
    return buf, nil
}

becomes

func ReadFile(path string) ([]byte, error) {
    f, err := os.Open(path) return nil, errors.Wrap(err, "open failed")
    defer f.Close()

    buf, err := ioutil.ReadAll(f) return nil, errors.Wrap(err, "read failed")
    return buf, nil
}

Maybe we could omit some tokens making them inferred

func ReadFile(path string) ([]byte, error) {
    f := os.Open(path) return errors.Wrap(err, "open failed")
    defer f.Close()

    buf := ioutil.ReadAll(f) return errors.Wrap(err, "read failed")
    return buf, nil
}

@mrkaspa
Copy link

mrkaspa commented Nov 20, 2017

what about this

func ReadFile(path string) ([]byte, error) {
    f, err := os.Open(path) !! return nil, errors.Wrap(err, "open failed")
    defer f.Close()

    buf, err := ioutil.ReadAll(f) !! return nil, errors.Wrap(err, "read failed")
    return buf, nil
}

The !! operator indicates what to do if the operation fails, and the variables on the left side are accessible on the right side, although this could make the lines longer.

@Azareal
Copy link

Azareal commented Nov 20, 2017

I don't think my idea is a good idea at all, but I'm just throwing it here as an idea.
It would basically function like a ternary operator.

err := doSomething()
(err != nil) ?! : return err

By the way, you can do ```go for Go syntax highlighting on Github.

@ianlancetaylor
Copy link
Contributor

This idea does not address the main issue discussed in #21161, which is to provide a simpler mechanism for wrapping an error as appropriate. This only simplifies returning an existing error, not wrapping it.

Closing in favor of a general Go 2 rethink of error handling.

@golang golang locked and limited conversation to collaborators Feb 27, 2019
@bradfitz bradfitz added the error-handling Language & library change proposals that are about error handling. label Oct 29, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
error-handling Language & library change proposals that are about error handling. FrozenDueToAge LanguageChange Proposal v2 A language change or incompatible library change
Projects
None yet
Development

No branches or pull requests

7 participants