I agree this is the best way forward: fixing the most common issue with a simple design.

I don't want to bikeshed (feel free to postpone this conversation), but Rust went there and eventually settled with the ? postfix operator rather than a builtin function, for increased readability.

The gophercon proposal cites ? in the considered ideas and gives three reason why it was discarded: the first ("control flow transfers are as a general rule accompanied by keywords") and the third ("handlers are more naturally defined with a keyword, so checks should too") do not apply anymore. The second is stylistic: it says that, even if the postfix operator works better for chaining, it can still read worse in some cases like:

check io.Copy(w, check newReader(foo))

rather than:

io.Copy(w, newReader(foo)?)?

but now we would have:

try(io.Copy(w, try(newReader(foo))))

which I think it's clearly the worse of the three, as it's not even obvious anymore which is the main function being called.

So the gist of my comment is that all three reasons cited in the gophercon proposal for not using ? do not apply to this try proposal; ? is concise, very readable, it does not obscure the statement structure (with its internal function call hierarchy), and it is chainable. It removes even more clutter from the view, while not obscuring the control flow more than the proposed try() already does.

To clarify:

Does

func f() (n int, err error) {
  n = 7
  try(errors.New("x"))
  // ...
}

return (0, "x") or (7, "x")? I'd assume the latter.

Does the error return have to be named in the case where there's no decoration or handling (like in an internal helper function)? I'd assume not.

Your example returns 7, errors.New("x"). This should be clear in the full doc that will soon be submitted (https://golang.org/cl/180557).

The error result parameter does not need to be named in order to use try. It only needs to be named if the function needs to refer to it in a deferred function or elsewhere.

I am really unhappy with a built-in function affecting control flow of the caller. This is very unintuitive and a first for Go. I appreciate the impossibility of adding new keywords in Go 1, but working around that issue with magic built-in functions just seems wrong to me. It's worsened by the fact that built-ins can be shadowed, which drastically changes the way try(foo) behaves. Shadowing of other built-ins doesn't have results as unpredictable as control flow changing. It makes reading snippets of code without all of the context much harder.

I don't like the way postfix ? looks, but I think it still beats try(). As such, I agree with @rasky .

Edit: Well, I managed to completely forget that panic exists and isn't a keyword.

The detailed proposal is now here (pending formatting improvements, to come shortly) and will hopefully answer a lot of questions.

@dominikh The detailed proposal discusses this at length, but please note that panic and recover are two built-ins that affect control flow as well.

One clarification / suggestion for improvement:

if the last argument supplied to try, of type error, is not nil, the enclosing function’s error result variable (...) is set to that non-nil error value before the enclosing function returns

Could this instead say is set to that non-nil error value and the enclosing function returns? (s/before/and)

On first reading, before the enclosing function returns seemed like it would eventually set the error value at some point in the future right before the function returned - possibly in a later line. The correct interpretation is that try may cause the current function to return. That's a surprising behavior for the current language, so a clearer text would be welcomed.

I think this is just sugar, and a small number of vocal opponents teased golang about the repeated use of typing if err != nil ... and someone took it seriously. I don't think it's a problem. The only missing things are these two built-ins:

https://github.com/purpleidea/mgmt/blob/a235b760dc3047a0d66bb0b9d63c25bc746ed274/util/errwrap/errwrap.go#L26

Not sure why anyone ever would write a function like this but what would be the envisioned output for

try(foobar())

If foobar returned (error, error)

I retract my previous concerns about control flow and I no longer suggest using ?. I apologize for the knee-jerk response (though I'd like to point out this wouldn't have happened had the issue been filed after the full proposal was available).

I disagree with the necessity for simplified error handling, but I'm sure that is a losing battle. try as laid out in the proposal seems to be the least bad way of doing it.

@webermaster Only the last error result is special for the expression passed to try, as described in the proposal doc.

Like @dominikh, I also disagree with the necessity of simplified error handling.

It moves vertical complexity into horizontal complexity which is rarely a good idea.

If I absolutely had to choose between simplifying error handling proposals, though, this would be my preferred proposal.

It would be helpful if this could be accompanied (at some stage of accepted-ness) by a tool to transform Go code to use try in some subset of error-returning functions where such a transformation can be easily performed without changing semantics. Three benefits occur to me:

• When evaluating this proposal, it would allow people to quickly get a sense for how try could be used in their codebase.
• If try lands in a future version of Go, people will likely want to change their code to make use of it. Having a tool to automate the easy cases will help a lot.
• Having a way to quickly transform a large codebase to use try will make it easy to examine the effects of the implementation at scale. (Correctness, performance, and code size, say.) The implementation may be simple enough to make this a negligible consideration, though.

Although the discussion on this issue is concluded, I'd like to introduce my library, which offers a solution to the problem we've been addressing through try proposal.

One notable question from the try design document is:

If Go had “generics”, couldn’t we implement try as a generic function?
The implementation of try demands the ability to return from the function that calls try. Without a "super return" capability, try cannot be realized in Go, even with generic functions. Moreover, try necessitates a variadic parameter list that accepts different types. The anticipation for variadic generic functions of such nature is low.

My library leverages generics to replicate try's functionality, circumventing these limitations. It introduces distinct functions for handling functions with different return counts. For instance, Check1 is designed for functions with a single return value, while Check2 caters to those with two. This approach simplify function calls, exemplified by:

x := e.Check1(strconv.Atoi(a))

I know this issue is closed but I think it wort to share my library here that addressing the issue that we trying to solve with try or catch

One of the question in the try design document is as follow:

If Go had “generics”, couldn’t we implement try as a generic function?
Implementing try requires the ability to return from the function enclosing the try call. Absent such a “super return” statement, try cannot be implemented in Go even if there were generic functions. try also requires a variadic parameter list with parameters of different types. We do not anticipate support for such variadic generic functions.

I implemented a library that using generics to achieve the same functionality of the try. The difference in here for different return type I created a separate function.e.g Check1,work with function have 1 return, Check2 work with function have two return. In this way we can simplify calling functions
Example call will be:

x := e.Check1(strconv.Atoi(a))

To handle errors, the Check function triggers a panic. Errors can be caught using a defer statement alongside named returns in HandleReturn function to capture and assign the error.

Check function "panic" the error. Now we need to catch the error via defer statement.
We can use named return and HandleReturn function to catch error and set the error.

A complete usage example is as follows:

func printSum(a, b string) (err error) {
    defer e.HandleReturn(func (e error){
        err = e
    }
    x := e.Check1(strconv.Atoi(a))
    y := e.Check1(strconv.Atoi(a))
    fmt.Println("result:", x + y)
    return nil
}

Additionally, custom error handlers can be used with the Check function to tailor error handling or add context to errors.

Custom error handler can be used as follow:

func printSum(a, b string) (err error) {
    defer e.HandleReturn(func (e error){
        err = e
    }
    
    convertionError:= func (err error) error {
            return fmt.Errorf("failed to convert to int: %w", err)
     } 
    
    x := e.Check1W(strconv.Atoi(a)).With(convertionError)
    y := e.Check1W(strconv.Atoi(a)).With(convertionError)
    fmt.Println("result:", x + y)
    return nil
}

For more detailed examples and to explore the library further, please visit: https://github.com/mfatihercik/errless.

If it is a closed issue, why can it still be commented? There are a lot of comments over the years

People can still discuss the idea even though we aren't going to adopt it.