(On | No) Syntactic Support for Error Handling

You make it out like the Go Team are programming language design wizards and people here are breezily proposing solutions that they must have considered but lets not forget that the Go team made the same blunder made by Java (static typing with no parametric polymorphism) which lies at the root of this error handling problem, to which they are throwing up their hands and not fixing.

This is so entrenched into everybody writing Haskell code, that I really can't comprehend why that was not considered. Surely there must be somebody in the Go community knowing about it and perhaps appreciating it as well? Even if we leave out everybody too intimidated by the supposed academic-ness of Haskell and even avoiding any religios arguments.

I really appreciate the link to this page, and overall its existence, but this really leaves me confused how people caring so much about their language can skip over such well-established solutions.

Relative amateurs assuming that the people who work on Go know less about programming languages than themselves, when in almost all cases they know infinitely more.

The amateur naively assumes that whichever language packs in the most features is the best, especially if it includes their personal favorites.

The way an amateur getting into knife making might look at a Japanese chef's knife and find it lacking. And think they could make an even better one with a 3D printed handle that includes finger grooves, a hidden compartment, a lighter, and a Bluetooth speaker.

The idea that "the happy path is the most common" is a total lie.

    a + b

So, errors are everywhere. And you must commit to a way to handle it and no is not possible, like no, not possible to satisfy all the competing ideas about it.

So there is not viable to ask the community about it, because:

    a + b

So, you pick a side and that is.

There is no such a thing.

Did Rust become a clusterfuck like C++?

Is Go as timeless as it was during release?

What? Survey says 13% mentioned error handling.

And some people actually do prefer it as is.

https://go.dev/blog/survey2024-h1-results

This is entirely subjective and paints the Go community as being paradoxical, simultaneously obstinate and wanting change.

The disappointing reality is that Go's error handling is the least terrible option in satisfying the language design ethos and developers writing Go. I have a penchant for implementing V's style of error handling, though I understand why actually implementing it wouldn't be all sunshine and rainbows.

    if err == nil { // inverted
        return err
    }

The current solution is fine, and it seems to be only junior/new to golang people who hate it.

Everyone I know loves the explicit, clear, easy to read "verbose" error handling.

All is well, no need to question your language or the meaning of life.

When you make a mistake irl or trip over when walking, do you reconsider you DNA and submit a patch to God?

Sometimes you just gotta have faith in the language and assume it like an axiom, to avoid wasting energy fighting windmills.

I'm not a deep Go programmer, but I really enjoy how it's highly resistant to change and consistent across it's 15 years so far.

A policy of handling errors usually ends up turning into a policy of wrapping errors and returning them up the stack instead. A lot of busywork.

And this is exactly where Go fails, because it allows you to completely ignore the error, which will lead to a crash.

I'm a bit baffled that you correctly identified that this is a requirement to produce robust software and yet, you like Go's error handling approach...

[1]: https://borgo-lang.github.io/ | https://github.com/borgo-lang/borgo

Hell, you can mostly replicate Gos "error handling" in any language with generics and probably end up with nicer code.

If your answer is "JavaScript" or "Python", well, that's the common pattern.

Even bash has -e :)

I thought it was clever in C# years ago when I first used to to grok all the try/catch/finally flows including using and nested versions and what happens if an error happens in the catch and what if it happens in the finally and so on. But now I'd rather just not think about that stuff.

I don't believe this claim is made anywhere.

We've decided that we are not going to make any further attempts to change the syntax of error handling in the foreseeable future. That frees up attention to consider other issues (with errors or otherwise).

We're both Googlers here and this is so disappointing to be let down again by the Go team.

Go is fascinating in how long it holds out on some of the most basic, obviously valuable constructs (generics, error handling, package management) because The Community cannot agree.

- Generics took 13 years from the open source release.

- 16 years in there isn’t error handling.

- Package management took about 9 years.

There’s value to deliberation and there’s value to shipping. My guess is that the people writing 900 GH comments would still write Go and be better off by the language having something vs. kicking the can down the road.

But meanwhile it's just perfectly idiomatic Erlang and Elixir, none of that baggage required. (In fact, the sum types are vastly more powerful than in the ML lineage - they're open.)

The convenience of writing `?` means nobody will bother wrapping errors anymore. Is what I understand of this extremely dubious argument.

Since you could just design your `?` to encourage wrapping instead.

Mostly because it is not entirely clear what the Rust-style equivalent in Go might be. What would Rust's "From" look like, for example?

- It isn't easily breakpointable.

- It favors "bubbling up" as-is over enriching or handling.

  x, err := strconv.Atoi("123")
  if err != nil {
    panic(err)
  }
  y, err := strconv.Atoi("1234")
  fmt.Println("result:", x, y)

Okay, I don't use golang... but I thought ":=" was "single statement declare-and-assign".

Is it not redeclaring "err" in your example on line 5, and therefore the new "err" variable (that would shadow the old err variable) should be considered unused and fail with 'declared and not used: err'

Or does := just do vanilla assignment if the variable already exists?

If you’re willing to share, I’m very curious to see a code example of what you mean by this.

How do you do that with this suggestion?

Did anyone propose this in one of the many error handling proposals?

Could in some purely theoretical way, but this is pretty much exactly the same, minor syntax differences aside, as virtually every other failed proposal that has been made around this. It would be useless in practice.

In the real world it would have to look more like this...

    func printSum(a, b string) result[error, unit] {
        return for {
            x <- strconv.Atoi(a) else (err error) {
                details := collectDetails(a, b)
                stop firstConvError{err, details}
            }
            y <- strconv.Atoi(b) else (err error) {
                stop secondConvError{err}
            }
        } yield fmt.Println("result:", x + y)
    }

   func printSum(a, b string) result[error, unit] {
        return for {
            x <- strconv.Atoi(a)
            y <- strconv.Atoi(b)
        } yield fmt.Println("result:", x + y)
    }

    handle(printSum, "x", func(vars map[string]any, err error) {
        details := collectDetails(vars["a"].(string), vars["b"].(string))
        return firstConvError{err, details}
    }

    handle(printSum, "y", func(vars map[string]any, err error) {
        return secondConvError{err}
    }

Once you start dealing with the realities of the real world, it is not clear how your approach is any better. It is pretty much exactly the same as what we have now. In fact, it is arguably worse as the different syntax doesn't add anything except unnecessary complexity and confusion. Which is largely the same reason why all those aforementioned proposals failed. Like the linked article states, syntax is not the problem. The problem is that nobody to date knows how to solve it conceptually without completely changing the fundamentals of the language or just doing what you did, which is pointless.

And there is another obvious problem with your code: result[error, unit], while perfectly fitting in other languages designed with that idea in mind, is logically incorrect in the context of Go. They are not dependent variables. It doesn't make sense to make them dependent. For it to make sense, you would, as before, have to completely change the fundamentals of the language. And at that point you have a band new language, making any discussion about Go moot. That said, I think the rest of your idea could be reasonably grafted onto the (T, error) idiom just as easily. However, it still fails on other problems, so...

[1] Which, I will add, is not just speculation. The Go team actually collected data about this as part of their due diligence. One of the earlier proposals was on the cusp of acceptance, but in the end it wasn't clear who – outside of contrived HN comments – would ever use it due to the limitations spoken of above, thus it ultimately was rejected on that basis.

It's too easy to accidentally write `if err == nil` instead of `if err != nil`. I have even seen LLMs erroneously generate the first instead of the latter. And since it's such a tiny difference and the code is riddled with `if err != nil`, it's hard to catch at review time.

Second, you're not forced by the language to do anything with the error at all. There are cases where `err` is used in a function that not handling the `err` return value from a specific function silently compiles. E.g.

    x, err := strconv.Atoi(s1)
     if err != nil {
      panic(err)
     }
     y, err := strconv.Atoi(s2)

    fmt.Println(x, y)

It "breaks" the language in fundamental ways — much more fundamental than syntactic sugar for error handling — by making zero values and thus zero initialisation invalid.

You even get this as a fun interaction with generics:

    func Zero[T any]() T {
        var v T
        return v
    }

You can also add additional context to the error before bubbling it up. But yes, that part of the point. Instead of bubbling them up, the programmer should instead reflect on whether it is better than just log and proceed, or completely swallow them. This is what error handling is about.

You can't bubble up an exception, it's done automatically. That's a very important distinction. You can't make the decision to bubble up or not, because you do not have the required information - you don't know whether an exception can be thrown or not at any point. Therefore, you can't say you're making a decision at all.

Explicit error allows you to be able to make the decision.

1. The very fact that adding more text isn't really any more verbose than not encourages you to add more text, making errors more informative.

2. A non-negligible amount of times you do something else: carry on, or do something specific based on what kind of error it was. For instance, ignore an error if it's in a certain class; or create the file if it didn't exist; and so on.

Forcing the error handling doesn't seem to me that different than forcing you to explicitly cast between (say) int and int64. Part of me is annoyed with that too, but then I have PTSD flashbacks from 20 years of C programming and appreciate it.

    v, err := foo.Open()
    // …
    defer func() {
        if closeErr := v.Close(); closeErr != nil {
            err = fmt.Errorf("while closing %w: %v", err, closeErr)
        }
    }() 
  
    // …

FWIW I love Go, it’s my daily driver for most things. I still think it can get messy far too quickly

How well does it work in practice?

And even then this is just the same as the '?' operator Rust uses, which is mentioned in the post.

All of that aside, I've come to learn that passing errors up the call stack without any wrapping or handling is a code smell. It is less than useless for me to attempt setting the value of cell A1 in an Excel sheet to "Foo" and then receive an out-of-range error because the developer made no attempt to even inform me of the context around the error. Let alone handling the error and attempting to correct state before giving up.

In my Excel example, the cause of the error was a data validation problem a couple columns over (F or so). The error was legitimately useless in troubleshooting.

It's not my impression Go is dying. Seems rather overblown.

And this "but $other_lang has it! You must have it! Adapt or die!" type of reasoning is how you end up with C++.

Every person/company using Go chose to use it knowing how errors are handled.

Each new way of error handling seems to upset a large number of users, some of which may not have chosen Go had the newer system been in place originally.

If it is impossible to know which choice is correct, at least everyone has some baseline level of acceptance for the status quo.

Go forces you to be explicit about error handling. Java syntax is not that much better. JavaScript, Kotlin, Swift,... is more about avoiding null pointer exception than proper error handling.

And FWIW, my hatred of go error handling has not diminished with increased usage.

You mean "verbose error handling". All other proposals are also explicit, just not as verbose.

  x = foo() ||| <error case>
  <happy case>

That is shorter and keeps the happy path unindented, even if it has additional such constructs, for example

  x = foo() ||| return Error(err, “foo failed”)
  y = bar() ||| return Error(err, “bar failed”)

That's really not true. Multiple return values means you always need to return some return value and some error value, even if they are dummy values (like nil). While a result type / sum type genuinely only contains one branch, not the other.

If you had a language that didn't have nil, it would genuinely be impossible to emulate sum type like behavior on top of multiple return values. It serves as an escape hatch, to create a value of some type when you don't actually have a meaningful value to give.

std::variant / std::expected / std::optional aren't syntactic sugar for std::pair either.

I you are right that this is the truth of it. Error handling just isn’t that big a problem. 13% reported it on the survey cited. That doesn’t seem that significant. And honestly, after writing Go, I barely notice error handling as I’m writing/reading code anyway. If anything I appreciate it a bit more than exceptions.

Always something that can be complained about. But it doesn’t mean every complaint is a huge deal.

It seems that now that Ian's left the rest of the Go team is just being honest about what they are willing to spend their time on.

And I'm more than fine with that, because look at this comment section. You can't please everybody.

Why debacle?

> After so many years of trying, with three full-fledged proposals by the Go team and literally hundreds (!) of community proposals, most of them variations on a theme, all of which failed to attract sufficient (let alone overwhelming) support, the question we now face is: how to proceed? Should we proceed at all?

> We think not.

  n := strconv.Atoi(s) or |err| {
      return fmt.Errorf("foo: %w", err)
  }

  n := strconv.Atoi(s) or |err| {
      if !errors.Is(err, pkg.ErrFoo)
          return fmt.Errorf("foo: %w", err)
      }
  }

I'm just making up syntax here to illustrate the point; doesn't look too brilliant to me. A func might be a bit more "Go-like":

  n := strconv.Atoi(s) or func(n int, err error) {
      return fmt.Errorf("foo: %w", err)
  }

It's reviewing mountains of that crap that's the problem, especially if there are non-trivial cases hidden in there, like returning the error when `err == nil` (mentioned by others in this thread).

> I work mostly in Go. I’m confident the designers of the Go programming language didn’t set out to produce the most LLM-legible language in the industry. They succeeded nonetheless Go has just enough type safety, an extensive standard library, and a culture that prizes (often repetitive) idiom. LLMs kick ass generating it.

https://news.ycombinator.com/item?id=44163063 - 2386 comments

Error handling in Go is not just writing "if err != nil { return nil, err }" for every line. You are supposed to enrich the error to add more context to it. For example:

    result, err := addTwoNumbers(a, b)
    if err != nil {
      return fmt.Errorf("addTwoNumbers(%d, %d) = %v", a, b, err)
    }

Not to mention, those helper functions don't account for cases where you don't just want to bubble up an error. What if you want to do more things, like log, emit metrics, clean up resources, and so on? How do you deal with that with the "Handle()" function?

    $ find . -name "*.go" | xargs grep 'if err !=' | wc -l   
     242
    $ find . -name "*.go" | xargs grep 'if err ==' | wc -l
      12

If you discard that as "error handling noise", you're in for a bug. Which is, by the way, perhaps the worst side-effect of verbose, repetitive error handling.

Apropos syntax highlighting: many themes in regular use (certainly most of the defaults) choose a low-contrast color for the comments. The comments are often the most important part of the code.

Everyone feels equipped to have an opinion about "what should be the syntax for an obvious bit of semantics." There's no expertise required to form such an opinion. And so there are as many opinions on offer as there are Go developers to give them.

Limit input on the subject to just e.g. the people capable of implementing the feature into the Go compiler, though, and a consensus would be reached quickly. Unlike drive-by opinion-havers, the language maintainers — people who have to actually continue to work with one-another (i.e. negotiate in an indefinite iterated prisoner's dilemma about how other language minutiae will work), are much more willing to give ground "this time" to just move on and get it working.

(Tangent: this "giving ground to get ground later" is commonly called "horse trading", but IMHO that paints it in a too-negative light. Horse trading is often the only reason anything gets done at all!)

The thing is, inaction is not simply "not taking an action"; Inaction is taking active action of accepting the current solution.

> I doubt that the best proposals are so horrible for some people that they’d hold a grudge and leave Go.

But people may leave go if they constantly avoid fixing any of problems with the language. The more time passes, the more unhappy people become with the language. It will be a death by a thousand cuts.

I love go. But their constant denial do fix obvious problems is tiring.

Invalid comparison - eating one foodstuff or another affects a few people for a few hours. Significantly changing a popular language affects every single user of it forever.

Not in this case. The most popular Go proposal/issue of all times was 'leave "if err != nil" alone': https://github.com/golang/go/issues?q=is%3Aissue%20%20sort%3...

I'd understand if they decided they needed more time to continue iterating on and analyzing proposals to find the right solution, but simply declaring that they'll just suspend the whole effort because they can't come to a consensus is rather infuriating.

Go chose not to change the error handling - Nature remained in balance.

Agreement on a problem does not imply agreement on a solution.

It's not about perfection. It's about not having a solution that gets anywhere near a majority approval.

Let's say your neighborhood has an empty plot of land owned by the city that is currently a pile of broken chunks of concrete, trash, and tangled wire. It's easy to imagine that there is unanimous agreement by everyone in the neighborhood that something better should be placed there.

But the parents want a playground, the pet owners want a dog park, the homeless advocates want a shelter, the nature lovers want a forest, etc. None of them will agree to spend their tax dollars on a solution that is useless to them, so no solution wins even though they all want the problem solved.

According to 13% of respondents. So yes, it's the "#1 issue", but also not by a huge overwhelming majority or anything.

- I need to do string interpolation: am I using f-strings or `string.format` or the modulo operator?

- I need to do something in a loop. Well, I can do that. But I could also just do a list or sequence comprehension... Or I could get fancy and combine the two!

And such and so-on, but these are the top examples.

Changing these things strictly adds cognitive load because you will eventually encounter libraries that use the other pattern if you're familiar with the one pattern. And at the limit of what this can do to a language, you get C++, where the spec exceeds the length of the Bible and many bits of it create undefined behavior when used together.

I think Go's project owners are very justifiably paranoid about the consequences of opening the Pandora's box on new features, even if it means users have to deal with some line-noise in the code.

"Errors are values", sure. Numbers are values and Lists are values. I use them differently, though.

I wonder if there could be "stupid" preprocessing step where I could unclutter go code, where you'd make a new token like "?=", that got replaced before compile time. For instance, "x ?= function.call();" would expand to "x, err := function.call(); if (err != nil) return err;"

I foresee endless PR arguments about whether err != nil is the best practice or whatever alternative exists. Back-and-forth based on preference, PRs getting blocked since someone is using the "other" style, etc. Finally the org is tired of all this arguing and demands everyone settle on the one true style (which doesn't exist), and forces everyone to use that style. That is where the "forced to use it" comes from.

From the early days, Go has taken principled stands on matters like this, striving for simplicity and one way to do something. For example, `go fmt` cut through all the tabs vs. space nonsense by edict. "Gofmt's style is no one's favorite, yet gofmt is everyone's favorite."

The decision is disappointing, but understandable.

The blog post attempted to explain it, but it comes down to: A lot of energy has been expended without the community and the core team reaching any form of consensus. The current error handling mechanism has entrenched itself as idiomatic for a very long time now. And since the promising ones among the various proposals involve language changes, the core team, which is stretched already, isn't willing to commit to it at this time, especially given the impact.

But now a sort of democracy is required for changes. I’m not sure this is necessary.

I have many things to complain about for other languages that I’m sure are top-tier complaints too

I wouldn’t be surprised that when the pro-exception-handling crowd eventually wins, it will lead to hard forks and severe fragmentation of the entire ecosystem.

Some languages even make omitting error handling impossible! (e.g. Result sum types). None have anywhere near the amount of "whining" Go seems to attract

What error are you talking about?

> For the foreseeable future, the Go team will stop pursuing syntactic language changes for error handling