alt Hacker News(On | No) Syntactic Support for Error Handling
Comments
Slowly reinventing exceptions seems to go against the spirit of Go. That is what you read is what you get.
Haskell solves this with the do notation, but the price is understanding monads. Go also aims to be easy to understand.
IDE's could help and just hide standard `if err != nil return fmt.Errorf("sh: %w", err)` blocks for us, or show them in some distinct way, like question mark after the statement.
I'm so happy that Rust sorted this out way early in its lifetime. Error handling is so nice there.
Can't believe we're going to get GTA 6 before an agreed upon (cleaner) error handling pattern in Go.
I have hard time understanding why they didn't go with
func printSum(a, b string) error {
x := strconv.Atoi(a) or {
return error
}
y := strconv.Atoi(b) or {
return error
}
fmt.Println("result:", x + y)
return nil
}
Go’s philosophy is the problem: sometimes you need a few ways to do the same thing. And that’s okay. Sometimes the flow you’re trying to express in code just needs the error to go up and get handled at the top. Sometimes you want to act on it. Right now all you can do is act on it. So all the times you don’t need to act on it have to suffer? I call profuse bullshit. There is 100% a way to add terse compiler-enforced error handling (for the love of all things holy if nothing at all changed with the syntax at least there should be consensus that it’s a serious problem that the compiler can’t tell you “oops you forgot to handle that error”) to be added in a way that doesn't bifurcate API surfaces. You just have to do it even in the face of dissent. You have to compromise on your values for the good of the language. What is the damn problem with ? literally expanding to `if err != nil { \n return err \n }`? Just take small steps that improve everyone’s life. If you look for excuses not to improve error handling you’ll find them. Sadly that appears to be what has happened here. The entire language suffers because a vocal minority are sadists. Is it time for me to come back to Go? I think not.
The way elixir conventionally uses tuples and pattern matching is really good.
awesome I love noisy boilerplate in my code, it isn't annoying at all
Oh No! Is a much better name for error handling.
considering the recent post [1] on system correctness in amazon quoting "In 2014, Yuan et al. found that 92% of catastrophic failures in tested distributed systems were triggered by incorrect handling of nonfatal errors."
perhaps it's a good thing that error handling is so explicit, and treated as a regular code path.
Thankfully repetitive language is less of a problem now that we have AI. The current syntax is just "add error handling to this function" :)
I've never used Go but having used other languages with exception-based error handling, I get why Go decided to go in a different direction... but reading this over...
Okay, so surely some syntactic sugar could make it more pleasant than the
if (err != nil) {
return nil, err
}
... oh, Go doesn't have sum-types. Or pattern matching.
Could you at least do some kind of generic error handler so I can call
y := Handle(MyFuncThatCanReturnError(x))
... Okay, GoLang does not have tuples. Multiple returns must be handled separately.
Okay could I write some kind of higher-order function that handles it in a generic way? Like
y := InvokeWithErrorHandler(MyFuncThatCanReturnError, x)
No? That's not an option either?
... why do you all do this to yourselves?
makes you miss the `or die` idiom :)
Love it, focus on building with what we have.
Resist enshittification, the greatest advantage in foundational software is sometimes saying no to new features.
Now that I think about it, are there any color schemes or extensions that highlight the error handling logic differently so that one can better focus on the “main” logic flow of the code while the error handling logic is still there?
This feels like it's making it worse lol
I love Go, but this is almost farcically hilarious:
> The goal of the proposal process is to reach general consensus about the outcome in a timely manner. If proposal review cannot identify a general consensus in the discussion of the issue on the issue tracker, the usual result is that the proposal is declined.
> None of the error handling proposals reached anything close to a consensus, so they were all declined.
> Should we proceed at all? We think not.
The disconnect here is of course that everyone has opinions and Google being design-by-committee can’t make progress on user-visible changes. Leaving the verbose error handling is not the end of the world, but there’s something here missing in the process. Don’t get me wrong, I love inaction as a default decision, but sometimes a decision is better than nothing. It reminds me of a groups when you can’t decide what to have for dinner – the best course of action isn’t to not eat at all, it’s to accept that everyone won’t be happy all the time, and take ownership of that unhappiness, if necessary, during the brief period of time when some people are upset.
I doubt that the best proposals are so horrible for some people that they’d hold a grudge and leave Go. IME these stylistic preferences are as easily abandoned as they are acquired.
To put another way: imagine if gofmt was launched today. It would be absolutely impossible to release through a consensus based process. Just tabs vs spaces would be 100 pages on the issue tracker of people willing to die on that hill. Yet, how many people complain about gofmt now that it’s already there? Even the biggest bike shedders enjoy it.
Most discussions of language features immediately fall into the politician's syllogism:
https://en.wikipedia.org/wiki/Politician%27s_syllogism
I appreciate the Go language's general sense of conservatism towards change. Even if you're not a fan of it, I think it's admirable that there is a project staking out a unique spot in the churn-vs-stability design space. There are plenty of other projects that churn as fast as they can, which also has its pros and cons, and it's great to be able to see the relative outcomes.
PS: it's kind of hilarious how the blog post is like "there are hundreds of proposals and miles of detailed analysis of these", vs the commenters here who are like "I thought about this for five minutes and I now have an idea that solve everything, let me tell you about it".
I don't really understand this decision. They know from developer surveys that verbose and repetitive error handling is literally the number 1 issue. Seeking the perfection of syntax that everyone agrees on seems to be the enemy of providing some good alternative to the status quo.
Their comment about providing some new syntax and people being forced to use it seems off base to me. It's nice to not have multiple ways of doing things, but having only 2 when it comes to error handling does not seem like a big deal. I imagine people will just use their preference, and a large percentage of people will have a less verbose option if they want it.
Just to add my two cents—I’ve been writing Go professionally for about 10 years, and neither I nor any of my colleagues have had real issues with how Go handles errors.
Newcomers often push back on this aspect of the language (among other things), but in my experience, that usually fades as they get more familiar with Go’s philosophy and design choices.
As for the Go team’s decision process, I think it’s a good thing that the lack of consensus over a long period and many attempts can prompt them to formally define a position.
TLDR: we didn't fix it for such a long time that now it's too late to fix it. We won't be fixing it, thanks!
Edit: looking at the results of their H1 2024 survey, they're making a hard turn into AI, and most likely will be developing AI libraries to close the gap with Python.
Don't expect language features.
>For a while, the lack of generics surpassed complaints about error handling, but now that Go supports generics, error handling is back on top
>The Go team takes community feedback seriously
It feels like reading satire, but it's real.
Hopefully this is the final nail in the coffin for all the “but I have to handle my errors” whining.
Sigh. They failed.
Dudes, error handling is THE worst part of Go. All of it.
And not just the lack of the "?" operator. It's also the lack of stacktraces, the footguns with nils-that-are-not-nil, problems with wrapping, the leakage of internal error messages to users (without i18n).
Literally everything. And you're just shutting down even _discussions_ of this?
I’m somewhat surprised this was a topic that was deemed worthy of a blog post. It seems quite out of character with other blog posts on the Go blog which are usually about introducing a new feature. Sure, Go’s relatively verbose error handling has long been a source of controversy, but was it worth publishing a blog post just to say, effectively: “please shut up”?
The fundamental thing that try/catch and similar language structures give us is an error _boundary_. I feel that not having one is a weakness of the language. The nesting and syntax all serve the purpose of handling errors neatly. I think it works very well and Go has unsolved the problem.
I am not saying that the mechanism is perfect but it is more useful if we have it than not. IMO it's only weakness is that you never know if a new exception type is thrown by a nested function. This is a weakness for which we really don't have a solid solution - Java tried this with checked exceptions.
Go not using such a paradigm to me is bonkers. Practically every language has such a construct and how we use it best is pretty much convention these days.
I just wish the could stabilize the compiler before piling on more features.
I regularly run into internal compiler errors these days for pretty normal looking code.
It's getting to the point where I'm reluctant to invest more time in the language right now.
UPDATE: See comment below for full error message and a link to the code.
Everything is fine
I dream if err, if err dreams me.