I second this. I really like how decorating every error before returning it adds human readable documentation to the source (usually we format our errors as "could not [what I am doing in these lines of code]: [previous error]") and also to the users reading errors.

Errors generated this way are extremely informative and much easier to read than stack traces. Printed errors that include stack traces usually assume you have ready access to sources (administrators might not have such access) and actually know your way in the code.

Errors without any form of context or tracing (the bare string "EOF") are absolutely useless. I think having shortcuts that make it easier to return naked errors will make Go programs print a lot of useless errors.

If anything, we should push and support decorating errors with context, maybe with new vet and lint rules.

I also like the explicitly error check. try is confusing and the implicit return is strange.

I think that instead of rethinking errors, we could try an alternative approach to make these checks shorter.

Here's an example which I don't necessarily agree:

value, err := foo()
return err if err != nil

This would allow an shorter but still explicit approach. And it'd allow adding context!

That said, inline ifs are a Ruby thing and don't feel very Goish, but this is just brainstorming. Maybe we find something else.

EDIT: I added a proposal for this here: #32860

there should be only one way of doing a thing

[...]Why not keep it as is?

I think it's fair to say that we all know the answer to this. You need only go read one of the various proposals to find out the answer if you sincerely don't know.

IMO, there's too little detail here for us to have a focused discussion (i.e. I don't think it qualifies as a proposal) and it will soon turn into another bike-shed full of circle-jerking and ideas that make the code less readable.

So much this.

Arguably I got into Go because of this explicit error handling. It sits somewhere between implicit try-catch that many languages go for and function types like Option or Maybe, which favors being returned to the user and be handled explicitly.

I'm not sure if a new construct would really solve this. If you wrapped if err := nil in a helper function like this, it might help a little (pardon my rusty Go):

func handleErr(err error, cb func(error)) {
        if err := nil {
                cb(err)
        }
}

But the issue that makes this helper function less generally useful is the type system, which is a different topic.

I second this. if err != nil { return err } is not part of any code in our code base. Therefore the try "macro" does not make any sense at all. We only return wrapped errors, with a message describing the context.

Adding context via defer does not make sense either, since we want to return different error messages to distinguish the different kind of errors. A try(fn(), "my error message: %w") might be useful though. But even then, the if err != nil construct might be still preferable, because of shorter line lengths.

Frankly, I don't want an implicit return that try provides. If we had generics, I would much prefer a solution that used monad-ish behaviour instead.

type Result<T> interface {
  Expect(err error) T
  OrElse(defaultValue T) T
}

func From<T>(value T, err error) Result<T> { ... }

To me, this is a lot cleaner than the builtin currently being proposed, although further changes would be required to the above since you'd have a proliferation of methods that returned (value, error) and Result

The current try proposal, having no way to explicitly decorate the errors, doesn't meet my needs. I can't imagine ever using it. Frankly, it might as well be called code_smell.

It might not make sense to change it, because the wrong problem is trying to be solved.

The code that we are familiar with is not error handling.

if err != nil {
  return err
}

This is error nil handling. At no point in this pattern is the value of an error handled.

If I were to demonstrate this in a different language, Ruby.

begin
 some_method_that_raises_an_error
rescue => e # catch any exception
  retry e        # throw it up again
end

This relays the same behavior as the golang code. When we detect that an exception occurred and then reraise it. We just throw it up the stack.

In golang, we return it.

Where is the actual error handling occurring?

We've all had similar experiences of the failure of this pattern. For example, receiving a file not found error and then spending a large length of time tracing the original thrower of this error.

This is why I believe the try proposal (and others) are faulting. We don't have a good pattern for actually handling errors.

I've see err.Error() string checking, type assertions, etc. to actually inspect the error.
We need a pattern for this inconsistency. It feels like xerrs might be solving this, but it also doesn't feel complete yet.

I support keeping err!=nil check as is.

Every time I dig into a sizable Go code base I ask myself how I might reduce some of the boilerplate. I always come back to:

• Those codepaths exist one way or another.
• Even if you're not required to hide the codepath, giving people the opportunity to hide it will make that the default behavior (because apparently we still measure how hard a language is to use by line count).
• If the default behavior hides codepaths then I'd be on the lookout for new "missing cleanup" bugs.
• The meaning and patterns for returned errors is diverse enough that this proposal would only capture a portion of the perceived issue
• If only a portion is captured then we'd surely get a bunch of solutions
• With a bunch of solutions would come the temptation to have some use-case adaptive magic to roll them up
• That if this were actually an issue then people are free to create their own simple solution or use some mass-adopted pattern. I haven't seen anything like that. Maybe I just haven't looked hard enough.

The issue tracker is useful for many things, but one thing it is not useful for is a detailed discussion of a complex topic. The issue tracker provides no threading, and replying to a specific message is awkward. Since there is no actual proposal here, just a response to other proposals, I really strongly encourage you to take this discussion to the golang-nuts mailing list.

If I may, I believe this is the answer. This new error proposal is in direct conflict with the goals of the language.

The reason I love golang is because of its simplicity and clear use of control flow. One of the things I despise most about Java is the try throw construct. It's so disgusting. It encourages terrible error handling. Sending exceptions up the call stack is a horrible and disgusting method of handling control flow. On top, it encourages wrapping everything in a giant check and calling it a day instead of a self documenting and explicit handling of each error situation.

If err != nil encourages good error handling, is self documenting and encourages good documentation as to the specific case, and it's honestly one of the things I love most about go. Making this new control flow interrupt, using messy, somewhat ambiguous returns and parameters, and confusing semantics is not in the spirit of the language I've come to adore.

Verbosity is not a bad thing. Unnecessary verbosity is, but I'd argue that go's error handling is not unnecessary. It's part of the language's charm.

Couldn't agree more. The explicit error handling is one of the best features of the language IMO. I always feel like many who are bothered by it just aren't used to it yet.

It is not good for the issues are separated, but I'm thinking that two opinions are merged as one opinion in this case.

1. We don't like new syntax (try or new if-err syntax)
2. Anyways, we don't want to add new syntax

GitHub vote icons can not interpret the second.

The explicit error handling in go is one of the reasons why I love golang. I don't understand why any go developer would want it any other way. I think the proposal to add new syntax is mostly from people comfortable using syntax used in other languages. it may take some getting used to but it works perfectly once you get use to it.

I wrote #32811 and I support this proposal more... I'd rather just leave error handling alone. I think the emoji reactions to this proposal say a lot.

I personally agree with leaving err handling as it is. One of things I like about Go is that the language is minimal, and generally speaking has one way of doing things. By adding new syntax for error handling, we’ll create a world where x% of code uses the current method, and y% uses the new method. This will, among other issues already discussed, create inconsistent code bases. I personally don’t think the value of new error handling syntax is worth the trade offs, since I consider the existing syntax enough/sufficient.

As someone that is newer to Golang, one of the things that I find refreshing about the language is the explicit error handling. I've worked in Java, Ruby, Python, and Node pretty heavily, and dealing with errors is so much more onerous than in Go. I would rather see the clear 'path' of errors, than have it implied to me by some language construct that makes it more vague.

ˋreturn ... if ...ˋ suggestion from @andreynering is actually fairly smart imho. Keeps the code explicit (no hidden control flow break) while cutting down the boilerplate (one-liner). ‬

Agree, leave if err != nil alone.

I prefer the current format. It is clear and an easy pattern to teach. Bringing new engineers up to speed is simple as they can learn one simple pattern and repeat it. It also asks the users to at least consider the error in the current context, ensuring that at least the engineer is acknowledging an error can occur here and I need to think about what to do.

I wrote #32804 and I would much rather see things NOT change. If your code is long, its because it does a lot of stuff. If you have a lot of error handling code, it's because you're doing a good job of handling all your cases.

Please, lets not add things just for the sake of adding things.

I enjoy the simplicity of the error handling as is.

Expect is just an anagram for except, and I'd rather not use it. Thanks for starting this.

Please don't change my holy grail.

There was overwhelming community feedback requesting more streamlined error handling (from the annual survey). The Go Team is now addressing that issue.

@icholy Sure, but the current proposals leave a lot to be desired. They all seem to either obfuscate the error handling, revert to more try/catch/finally style implementations, bubble the error handling up out of context, or otherwise make it more complicated. Since Go is supposed to be a simple language, I think a lot of us were hoping for a simple option. I haven't seen any I personally like, so I think that the better option is to keep the current pattern.

One complaint was having to type it, but virtually every editor has shortcuts to insert code snippets, so it really isn't a big deal. Perhaps it is my own experience having used Go since pre 1.0, but I happen to like the simplicity and don't mind the redundancy.

The try proposal has been withdrawn: #32437 (comment)

Generics anyone?

This is a proposal about the way gofmt currently formats if err != nil

I have tried that, imho the code is even more unreadable that way than with multi line formatting. try is much better than that solution.

IMO the problem here is rather not how the error handling is performed, but whether it is ignored. Wouldn't it be possible to leave the if err != nil syntax as is, but restrict the ignorance of the Error returns? Like make it a compiler warning/error with deseverity option for the legacy code.

IMO the problem here is rather not how the error handling is performed, but whether it is ignored. Wouldn't it be possible to leave the if err != nil syntax as is, but restrict the ignorance of the Error returns? Like make it a compiler warning/error with deseverity option for the legacy code.

Many people want a linter showing ignored errors.

I'd prefer making this a hard error, but looking at the tons of already written legacy, linter is fair as well.

As seen in the discussion on #32437, this proposal has in effect been accepted for now. Closing. If the issue arises again, a new proposal can be opened.

I'm starting to think that one of the reasons that a lot of the proposals feel like they don't quite fit right is because they're actually trying to address two different problems at the same time. On the one hand, it's true that having err != nil blocks after nearly every function call can break up the flow of the code in a weird way, although it certainly has its upsides, but I think that that's only half of the problem. The other issue is that handling multiple returns, regardless of whether there were errors involved or not, can be quite clunky.

Multiple return functions feel very, very different from single return functions, despite the seemingly small difference between the two. It's kind of like if there were extra restrictions on calling functions that take more than one argument. It feels very odd to deal with sometimes. When you call a function with multiple return values, you almost always need to do so on its own line, and it, combined with :=, is often the main source of the various variable shadowing problems that have been discussed elsewhere. You can't chain method calls onto them, you can't assign from them directly to a struct field and a new variable on the same line, and so on.

I don't know. Maybe it's just me. But I've used Go for nearly 10 years now and calling functions with multiple returns still feels kind of awkward to me sometimes.

Thank you!

There is one actually issue with if err != nil, the scope of err can live longer than it should. When you inline the if it solves the issue, but not all case can be inlined.

if err := foo(); err != nil {

if _, err := bar(); err != nil {

When you have other variables from needed after the handling creates a problem.

a, err := bar()
if err != nil {

Or the other way variable already exists.

var err error
baz.A, err = bar()
if err != nil {

The err variable should not exists in the function scope after the if err != nil {} block completes. Here is my proposal that builds off of the try() proposal to fix the issue #33161. I would love some constructive feedback.

The err variable should not exists in the function scope after the if err != nil {} block completes.

why "should" it not exist after the if block completes? The compiler can optimize for it (if it'd deem that necessary), and there's no mental load when the err := stmt()\nif err != nil {} block completes because these almost always go together.

I haven't yet looked at your proposal in depth (though kudo's for going through the effort of writing one!). However, as I also outlined in my comment above, I think more research is required into any perceived problems, before we dig into any proposals to resolve them.

@Freeaqingme errors should not exist after the if err != nil block completes, mostly because we already act like it doesn't.

In the CopyFile example, there is r, err := os.Open(src) followed by w, err := os.Create(dst). The second err is shadowing the first one. Shadowing variables is usually frowned upon.

There are also other oddities. If I have err := foo() and later something like bar.V, err = baz(), if the code is refactored and I no longer need foo() I would need to add var err error before the baz line. . I don't think that refactoring a different location in a function should affect other places like that.

Technically in

    r, err := os.Open(src)
    if err != nil {
        return ...
    }
    w, err := os.Create(dst)

the second instance of err does not shadow the first instance. They are actually the same variable. See the discussion of redeclaring variables at https://golang.org/ref/spec#Short_variable_declarations.

Frankly, I don't want an implicit return that try provides. If we had generics, I would much prefer a solution that used monad-ish behaviour instead.

type Result<T> interface {
  Expect(err error) T
  OrElse(defaultValue T) T
}

func From<T>(value T, err error) Result<T> { ... }

To me, this is a lot cleaner than the builtin currently being proposed, although further changes would be required to the above since you'd have a proliferation of methods that returned (value, error) and Result

It's so similar Rust‘s Ok and Err.
I think if err != nil {} maybe better one bit.

@Yanwenjiepy that's intentional, I'm big fan of Rust's Result type.

I'm less than 10 minutes into learning Go. The very first thing I noticed in the code I was looking at was had this copy pasted over, and over, and over again:

someValue, err := someFunction();
if err != nil {
  panic(err)
}

I'm obviously not an expert, but it might be of value that it's only taken me my first glance to end up on this thread.

That's because you're looking at code snippets for learning. Real code has to handle errors, not just panic and crash.

True, but errors can (and often should) be grouped. That's why try/catch blocks exist in other languages. For example, the following would smell much less like dinosaurs to me:

try {
  foo, throw err := someFunction();
  bar, throw err := foo.get();
  baz, throw err := bar.make();
  qux, throw err := baz.transform();
} catch(err) {
  // "Unable to foo bar baz qux."
  tryHarder();
}

Once again, total layman. But code is just symbols, and if they repeat enough, you can make a symbol for that too. This appears to be a very frequently repeating symbol.

You might want to take a look at Rob Pike's Errors Are Values post to see how you can use a helper to merge errors and deal with them all at once. In practice catching all exceptions with a single clause is considered bad style in most languages that have them, because you end up hiding information about what actually happened. (And if you extend the example to break out the individual caught exceptions and not throw that information away, the code ends up as long as the Go equivalent.)

Thanks for the link. The errWriter is a totally passable solution.

True, but errors can (and often should) be grouped. That's why try/catch blocks exist in other languages. For example, the following would smell much less like dinosaurs to me:

try {
  foo, throw err := someFunction();
  bar, throw err := foo.get();
  baz, throw err := bar.make();
  qux, throw err := baz.transform();
} catch(err) {
  // "Unable to foo bar baz qux."
  tryHarder();
}

Once again, total layman. But code is just symbols, and if they repeat enough, you can make a symbol for that too. This appears to be a very frequently repeating symbol.

Let's say each function returns overlapping error type and you must handle all function result gracefully, how do you write tryHarder()?

try {
  foo, throw err := someFunction();  // err could be TypeA and TypeB
  bar, throw err := foo.get();       // err could be TypeB and TypeC
  baz, throw err := bar.make();      // err could be TypeA and TypeC
  qux, throw err := baz.transform(); // err could be TypeB and TypeD
} catch(err) {
  tryHarder(); // tell me how to handle each error?
}

It will only take someone else 1 minute to understand the below code:

foo, err := someFunction();  // err could be TypeA and TypeB
if err != nil {
 // handle err
}

bar, err := foo.get();       // err could be TypeB and TypeC
if err != nil {
  // handle err
}

baz, err := bar.make();      // err could be TypeA and TypeC
if err != nil {
  // handle err
}

qux, err := baz.transform(); // err could be TypeB and TypeD
if err != nil {
  // handle err
}

Let's say each function returns overlapping error type and you must handle all function result gracefully

In that example, you're totally correct.