There is no try only do. Go errors are explicit, verbose and on the nose. If you hide it behind magic, you will have a bad time. If I read the code, I can clearly identify an error and what will happen if said error does occur. I don’t want to hide it! I want to see, read and be reminded of its existence. Otherwise, I might miss an important error.

Also, I’m adding different error messages for each error with fmt.Errorf. If I understand you correctly, I would have to have a different handler for each of those? That would obviously be a problem and just increase the complexity and number of lines further. 😃

I would love to have try, but as block and only to simplify existing Go error handling.

Inside try block, every non-nil assignment to err jumps to except and finally blocks.

Something like this:

  try(err) {
      err = someFunction()
      _ = someFuncWithErrIgnored()
      err = someOtherFunction()
  } except {
     // Something went wrong on first place err gets non-nil value
     return err
  } finally {
    // Like defer, but only for try block
    someCleanupFunc()
  }

I

Thanks for the proposal.

I am fully against it:

• how many keystrokes does it save? It actually adds more in many cases
• readability improvement: it worsens readability by introducing magic, also all IDEs today fold errors
• writeability improvement: it worsens writeability by introducing magic (see for example try/catch in Java, where behavior is difficult to predict in elaborate try/catch/finally cases)
• second order consequences: it opens the possibility of finally, universally recognized as a mistake in Java, and even worse, Optional

But, above all, it steepens significantly the learning curve:

Learning case one: erros are values, errors are there when a non nil value is detected

Learning case two: a special keyword, try, is introduced, that behaves in the following way: case 1… case 2… case 3, and code is autogenerated…

Basically it boils down to targeting people coming from Java/Javascript, where it’s easier, in the beginning, to read code that has “try”, so we obfuscate a clean language to make the learning curve shorter by one day.

Thanks for the proposal. My 2 cents: If try err is translated to return err, why write try err, handler to have it translated to return handler(err)? We could also write try handler(err), which is just cleaner and more understandable, and it could be lazily evaluated like a defer statement, so that the handler is not gonna be called if there is no error.

This is a great discussion all, clearly something a lot of people are interested in. I’ve been following along here and it seems we all just want less clutter for the most common use cases of error handling. So what if we took a little bit out of JavaScript’s playbook and even made it more terse:

if err { return fmt.Errorf("abc: %w", err) }

• The if err would obviously evaluate to if err != nil
• If the block is a single line, it would format like above
• It would return zero values for all other return values

@steerling thanks for pointing that out. Just this week I wrote a bug where I messed up the equality and wrote if err == nil and it got through code review. Granted, I am working to setup linters that will catch that, but ideally we wouldn’t need to rely on linters. The point is that rather than being highly readable, it ends up being a bunch of boilerplate that is glazed over. However, the !=nil is not as bad as having to insert zero values. Developers are tempted to return pointers to structs just so they can have something that is easy to write and read return nil, nil, err rather than return LongStructName{}, package.OtherStructName{}, err where the zero values are reducing readability.

I strongly believe we should not add the ThenErr error chaining in this proposal. Better error handling has been discussed a lot, so I’d call this a big change to the language. I’d recommend we keep the change small for its first iteration.

Some other things that stick out to me:

• I agree with other commenters that check or returnif is a better keyword. “Try” implies that you are trying something, but an error might occur. With this proposal, the “trying” has already occurred, and we’re simply checking if an error has occurred.
• Agree with other commenters that a comma looks too similar to multi-assign statements.
• It might be worth mentioning how handler might interact with a defer that interacts with named returns error params, although if the handler is just syntactic sugar for if err != nil {...}, then defer’s should continue to work as normal

I believe we put all the language changes for error handling on hold. We should probably do the same for this one.

A few people now (across this and some earlier proposals) have proposed alternatives which seem to involve combining the following two independent building-blocks:

• Some ability to use a value of type error in a context where boolean values are expected and have it convert to true if the error is non-nil and false if it’s nil. There have been various proposals that would amount to this before:
  • #21769
  • #32845
  • #33152
  • #33115.
• A shorthand for returning while specifying only one trailing return value, implicitly assigning zero value to any others. There are some other proposals which cover similar ground:
  • #21182
  • #35966

I think it’s instructive that of all of these at the time of writing only the second set remains open, and in particular the first set related to using error (or any other subset of nilable types) as a predicate seems to have been explicitly declined multiple times and is therefore not on the table unless there is new information to consider.

I think the shortest possible alternative using the above ideas, without using any mechanisms that have already been declined in previous proposals, would be something like:

if err != nil {
    return ..., err
}

or indeed, the one-liner form of that:

if err != nil { return ..., err }

…but that’s already essentially what #21182 proposes – the above uses nothing except a form of that proposal – and so that other issue is probably the better place to discuss the pros and cons of that approach, rather than here.

@gregwebs thanks for writing this proposal, even though I disagree with it.

@steerling thanks for pointing that out. Just this week I wrote a bug where I messed up the equality and wrote if err == nil and it got through code review. Granted, I am working to setup linters that will catch that, but ideally we wouldn’t need to rely on linters. The point is that rather than being highly readable, it ends up being a bunch of boilerplate that is glazed over. However, the !=nil is not as bad as having to insert zero values. Developers are tempted to return pointers to structs just so they can have something that is easy to write and read return nil, nil, err rather than return LongStructName{}, package.OtherStructName{}, err where the zero values are reducing readability.

I think this bug is a bad argument for if err != nil being a negative thing. This bug is a logic bug that should have been caught with a test. Errors being values and treated as regular code makes this simple.

A few general thoughts and opinions on the proposal.

This proposal arises from

1. perspective of the code writer

   IMO the perspective of the code reader is more important in programming languages than the perspective of the code writer. It is better for the writer to write a few more characters than for the code to be harder to read. I believe that current syntax would not have persisted if it were not easy to read.

   A quote from Uncle Bob on the idea of writability versus readability:

   Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. …[Therefore,] making it easy to read makes it easier to write.

2. the habit to see in other programming languages an additional syntax for error handling.

I like ? at the end of calls that could return an error. For example:

isEven, err := even(i)?

expands to

isEven, err := even(i)
if err != nil {
  return makeGenericWithDefault[bool](), err
}

I wrote a dumb script for my own use:

package main

import (
	"fmt"
	"os"
	"path/filepath"
	"regexp"
	"strings"
)

type FuncInfo struct {
	Name       string
	ReturnType string
}

var funcMap map[string]FuncInfo

func main() {

	// Check if there is at least one command-line argument
	if len(os.Args) < 2 {
		fmt.Println("Please provide a directory name")
		os.Exit(1)
	}

	// Get the last argument as the directory name
	dirName := os.Args[len(os.Args)-1]

	// Walk through the directory and its subdirectories
	err := filepath.Walk(dirName, func(path string, info os.FileInfo, err error) error {
		if err != nil {
			return err
		}

		// Check if the file has the .rgo extension
		if filepath.Ext(path) == ".rgo" {

			// Read the file content
			content, err := os.ReadFile(path)
			if err != nil {
				fmt.Println("Error reading file:", err)
				return err
			}

			code := string(content)

			funcMap = make(map[string]FuncInfo)

			findFunctions(code)

			code = replaceQuestionMarks(code)

			code += "\n" + strings.Trim(`func makeGenericWithDefault[T any]() T {
				var t T
				return t
			`, "\n\r\t ") + "\n}"

			// Write the modified code to a new file with the .go extension
			err = os.WriteFile(path[:len(path)-4]+".go", []byte(code), 0644)
			if err != nil {
				fmt.Println("Error writing file:", err)
				return err
			}
		}

		return nil
	})

	if err != nil {
		fmt.Println("Error walking directory:", err)
		os.Exit(1)
	}

}

func findFunctions(code string) {

	funcRegex := regexp.MustCompile(`func (\w+)\((.*?)\) \((.*?)\)`)

	matches := funcRegex.FindAllStringSubmatch(code, -1)

	for _, match := range matches {

		funcName := match[1]
		returnType := match[3]

		funcInfo := FuncInfo{
			Name:       funcName,
			ReturnType: returnType,
		}

		funcMap[funcName] = funcInfo
	}
}

func replaceQuestionMarks(code string) string {

	callRegex := regexp.MustCompile(`(\w+), err := (\w+)\((.*?)\)\?`)

	matches := callRegex.FindAllStringSubmatchIndex(code, -1)

	for i := len(matches) - 1; i >= 0; i-- {
		match := matches[i]

		start := match[0]
		end := match[1]

		funcName := code[match[4]:match[5]]

		funcInfo, ok := funcMap[funcName]

		if !ok {
			fmt.Println("Error: function not found:", funcName)
			os.Exit(1)
		}

		returnType := funcInfo.ReturnType

		if returnType == "" {
			fmt.Println("Error: function has no return type:", funcName)
			os.Exit(1)
		}

		returnTypes := strings.Split(returnType, ",")
		for i, t := range returnTypes {
			returnTypes[i] = strings.TrimSpace(t)
		}

		defaultValues := make([]string, len(returnTypes))

		for i, t := range returnTypes {
			switch t {

			case "error":
				defaultValues[i] = "err"
			default:

				defaultValues[i] = fmt.Sprintf("makeGenericWithDefault[%s]()", t)
			}
		}

		defaultValue := strings.Join(defaultValues, ", ")

		replacement := fmt.Sprintf("%s, err := %s(%s)\n\tif err != nil {\n\t\treturn %s\n\t}", code[match[2]:match[3]], funcName, code[match[6]:match[7]], defaultValue)

		code = code[:start] + replacement + code[end:]
	}

	return code
}

^{I am a beginner. My proposal is 99% certain to be stupid}

what abt

func x() (int, int, error) { ... }
a, b := try x(), fmt.Errorf("x err: %w")

have this been tried to be probosed before (i haven’t been keeping up)?

I didn’t read all the posts, but like others I though and read a lot about error handling in Go, I don’t have strong opinion, more thinking loud.

Is it really about adding a new keyword because of a missing functionality or is it about code format/readability?

if we can add a case to the go formatter to allow one line if with couple of statements like this

if err != nil { handle(err); return }

if err != nil { handle(err); return something, err }

if err != nil { log.Fatalln(err) }

borrowing from @gregwebs post above

func CopyFile(src, dst string) error {
    handler := func(err error) error {
            return fmt.Errorf("copy %s %s: %w", src, dst, err)
    }

    r, err := os.Open(src)
    if err != nil { handler(err); return }
    defer r.Close()

    w, err := os.Create(dst)
    if err != nil { return specialHandler(err) }
    defer w.Close()

    err = io.Copy(w, r)
    if err != nil { handler(err); return }
    err = w.Close()
    if err != nil { handler(err); return }
    return nil
}

func specialHandler(dst string, err error) error {
    os.Remove(dst) // only if Create fails
    return fmt.Errorf("dir %s: %w", dst, err)
}

Anyway, if error handling is more than one line beside return it should be in multiple lines, this way it explicitly describe the steps of error handling.

This proposal is rather inconsistent in the definition of try’s grammar. At the start of the proposal try’s arguments are introduced as “error and handler of type func(error) error”, but later in “Appendix: lazy error handlers” try is used with arguments of “error and function call”.

Additionally, in my opinion, this proposal is much more costly, that the author suggest. It’s not only the keyword to learn, but also a difference of when to use if err != nil idiom and when to use this syntax sugar. I believe this proposal may either introduce inconsistency in error handling, since one times the if err != nil would be used and other times the try statement with a handler, it won’t be possible for go vet to automatically figure out, which fits the best, or totally revolutionize the current approach at error handling. Moreover, it definitely introduces inconsistencies in ways of exiting a function, which would require a massive rework of all tools, that rely on analyzing that.

There is no try only do. Go errors are explicit, verbose and on the nose. If you hide it behind magic, you will have a bad time. If I read the code, I can clearly identify an error and what will happen if said error does occur. I don’t want to hide it! I want to see, read and be reminded of its existence. Otherwise, I might miss an important error.

I disagree that this proposal makes anything more “magical” or “hides” anything. This proposal provides syntactic sugar to handle an extremely common usecase and the final result is clearer more succinct code. I am personally okay with the current if err != nil way of error handling but this is indeed seen as somewhat of speedbump by many go developers.

It must be noted that this proposal maintains the current spirit of Go’s error handling- the errors remain explicit and one is free to drop into if err != nil blocks if that makes more sense in the current context while providing syntactic sugar for common usecases. Rust for example also provides a construct that is similar in spirit to what this tries to accomplish and it does not result in code being any less explicit or more magical.

If this is an essence of the past error proposals, you could make it easier for the occasional reader of go code, if you borrow the “return if” naming from proposals like #53017. The try statement from this proposal could simply be renamed to returnif:

  i, err := strconv.Atoi("42")
  returnif err, handler

This would better indicate that this is a return statement, and still allow to grep for “return” through the source code.

If you would addionally allow to infer the ‘!= nil’ comparision for values of type error in if statements, the operation could be made even more obvious. Then the returnif err statement could be a shorthand for returnif err != nil, err. And this would just be syntatic sugar for a checked return statement with zero value insertion:

  if err {
      return ..., err
  }

@apparentlymart thank you so much, I value your feedback and the time you have taken to properly understand the proposals. And I really appreciate how you have separated it out into 2 sections.

I think I will alter the proposal to put the content on defer into an appendix section. It’s definitely the part where I am thinking out loud about something I don’t have a great conclusion on yet.

this can be defined in a way that doesn’t special-case the error type:

In that case is is possible to do this transformation in the future then? But when I look to the future I hope for a language that has sum types and is using a result type and an option type. And I think this would only need to work for those two types. So attempting to generalize now to zero types may cause problems in the future.

As for the details not affecting acceptance:

I find check better

I actually prefer check as well, but have stuck with try for now because it is fewer characters.

Using a comma

What do you think about other possible options to replace a comma:

• a space
• a semi-colon (like for)
• keeping the comma, but enclosing the 2 in parentheses (like a function call)

Thanks for writing up this refined proposal, @gregwebs!

Although I have personally become accustomed to the “long form” of error handling in today’s Go and don’t feel a strong need to reduce it, I do also recognize that many other Go programmers – including those new to Go – find the current approach rather jarring/uncomfortable. Of all of the proposals for first-class error-flow-control constructs so far, this one is the one I feel most comfortable with because I can easily follow what it’s a shorthand for, without having to develop any complex new mental models once I’ve learned about the new keyword.

Some initial reactions below. Some of these are just clarifications to make sure I understood correctly, while others are actual feedback.

• Although framed as being for errors, on the surface it seems like this can be defined in a way that doesn’t special-case the error type:

  The expression which appears after try must be assignable to the last return value of the function. If activated, the try statement assigns that expression to the last return value and updates any other return values to be the zero value of their type.

  One hitch with this, though: if it’s broader than error then the implied if predicate is trickier to define, because not all types can be meaningfully compared to nil. Perhaps it could be defined as accepting anything which can be compared to nil, although that seems to get into non-orthogonal territory. Perhaps it is better after all to require error, if only because there’s a well-understood convention for whether an error value represents an error or not.

• The defer try variant feels a bit tricky. Defer is currently defined as being followed by an expression, but we’re intentionally making try a statement instead of an expression and so defer try is essentially a new statement in its own right here, which I see you already touched on in the proposal.

  Making defer try work seems like would invite questions about why defer if doesn’t work, if try is a shorthand for an if statement. However, I don’t personally feel that strongly about it and am only mentioning it for completeness; I can’t imagine any real situation where defer if would be clearer than a normal if statement inside a defer function.

• I retain my previous worry that the form of try with only one expression is so convenient (in comparison to the longer version which requires defining a separate error-transforming function) that folks will be tempted to use it in situations where it isn’t ideal.

  However, I can’t really argue that this isn’t already somewhat true for if err != nil { return err }. The fact that the expression in the return statement is an inline “lazy expression” (to copy the terminology from your proposal) does make it marginally more convenient, but as you pointed out it would be possible for try to treat its second argument that way if that turns out to be a significant concern.

I think the above is the extent of my initial substantive reaction. Everything else is details that I would not expect to affect the acceptance of the proposal. The following is therefore intended as presumptuous feedback for a subsequent effort to develop this from an accepted proposal into a final design, rather than for deciding whether to accept the proposal:

• try followed by a noun rather than a verb just reads weirdly to me. I find check better because it is a word that seems more naturally followed by a noun. I also like the idea of something involving return if possible, since that would really cement the idea that this is a shorthand for returning early.

  (try DoSomething() for a function which only returns an error doesn’t have this problem; it’s the form where we’re checking an error variable assigned in an earlier statement that I’m concerned about.)

• Using a comma between the error expression and the error transformer expression feels a bit too similar to the syntax for multiple return values or multiple assignment. I worry that a naive reader would presume that the second argument is somehow another value to be returned, rather than a function to be called. I’d recommend either another keyword or some different punctuation, to hopefully make it more obvious that the error transformer is something unique to this statement.

Thanks again!

maybe we just need a auto return keyword when error occred.

func doingSomething(src, dst string) (err error) {
    defer func() {
        if err != nil {
            fmt.Println("some error occred", err)
        }
    }()

    r, err := autoreturn os.Open(src)
    defer r.Close()

    w, err := autoreturn os.Create(dst)
    defer w.Close()

    err = autoreturn io.Copy(w, r)
    if err != nil {
        fmt.Println("handle error by manually")
        return err
    }
    return nil
}

@ianlancetaylor as a side note I think the model of using an issue as a proposal is broken. Proposing via pull request (as is commonly done in community RFC processes) would be a big improvement because it would allow for and encourage a clear discussion thread on a particular point of a proposal.

It doesn’t seem there is any new discussion on this proposal (instead just different proposals). The different proposals being posted here have all been proposed before.

Let me try to summarize the feedback on this proposal. If someone wants to chime in with major points that I missed, that would be appreciated. Otherwise I would be happy to close the discussion now.

The below are points that in theory are easy to resolve by altering the existing proposal:

• The name try does not capture the operation well, check and returnif are given as possible alternatives.
• The use of a comma separator is not liked by some because it looks like a multi-value return. with has been given as a possible alternative.
• Adding a ThenErr error handler function composition is dis-liked by many (it’s not clear to me why). An alternative is to not add it.
• defer try does not match how defer currently takes an expression. The alternative is to not add this.

Below are points that were raised about the benefits and costs of this proposal:

• There is some interest in generalizing these kind of proposals to work for other zero values in addition to just errors. But this has not been fully thought through. This could make the feature more powerful, and thus more worth it, or it may just be confusing and unworkable.
• It may be very difficult or at least a lot of work for tooling to adapt to this new statement. Thus this may be a difficult breaking change for some tools

And of course, there are a lot of value judgements about whether adding this new feature is worth the cost or otherwise the right thing to do for Golang. In the above I tried to write down any factual statements that came out of these, but sometimes they are hard to tease out.

1. Much like #define in c language, Or, maybe it’s better to add a define?
2. Just turned 3 lines of code ** if err!=nil{ // do somethine } ** into one or two lines，but with more implicit processing

func checkNilErr(err error, doIfErr func()) bool{
     if err != nil {
         doIfErr()
         return false
     }
     return true
}

func process() {
   errH := func() {
       // do somethine
   }


   // ...
   err := doSomethins()
   if !checkNilErr(err, errH) {return expr}    // So, try just shortens this line? but more inflexible
   
  // ...
}

Thanks for taking the time to make a proposal @gregwebs , while this would make it easier for newcomers, it is not to my taste. For some reason I don’t see this as “go” code. It seems to me that the solution you propose would only remove 1 line if err != nil while adding more lines for the handler(err) func in the end.

I like the idea of improving error handling, but to me, having try err, h(err) sprinkled in my code instead of if err != nil isn’t great. I’d stick with the old way if I had the option.

Sorry I’m not more helpful, but I can’t even nail down why I don’t like it, maybe it reminds me too much of ? hidden error returns, or flashbacks of Python’s exceptions… 😄

I would much rather see something akin to Rust’s Result<T, E> and Option<T> handling of errors and optionals, backed by the type system. I think those would be much more valuable, even though they would require more changes to the language.

A few general thoughts and opinions on the proposal.

This proposal arises from

1. perspective of the code writer IMO the perspective of the code reader is more important in programming languages than the perspective of the code writer. It is better for the writer to write a few more characters than for the code to be harder to read. I believe that current syntax would not have persisted if it were not easy to read. A quote from Uncle Bob on the idea of writability versus readability:

   Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. …[Therefore,] making it easy to read makes it easier to write.

2. the habit to see in other programming languages an additional syntax for error handling.

Speaking personally, I find the if err != nil clutter to decrease readability, so this proposal would help with that (for me at least)

@m3talsmith Thank you for helping to bring the tone of the conversation back to where it started

is the builder pattern proposed by the ThenErr a necessary part of this error handling proposal?

ThenErr is not required. It isn’t a builder pattern, it is a specialization of function composition. The point is really just that we can compose functions to stack handlers. There are different ways to achieve consumption. In my try library I allow additional handlers as extra arguments.

with respect to your example, I don’t quite understand it. It looks like you just got rid of the nil check, which has been proposed in the past. We are trying to keep the discussion centered on this proposal and small changes that could be made to it rather than different proposals.

@earlye there is already a proposal open that is the same as this but without error handler. In the appendix of my proposal and as a comment on that proposal I explain why error handlers should be first class.

@Skarlso I agree and I think that’s the idea behind the “lazy” appendix, which I think would be essential to make this useful.

try err, fmt.Errorf("f fail: %w", err)