Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Discussion: Reduce error handling boilerplate in Golang using '?'

github.com

Post reply on HN
Print view View original

11–20 of 94 posts

Re: Discussion: Reduce error handling boilerplate in Golang using '?'

#11

Post by pornel »

RedNifre wrote: post #3

(I'm not a Go programmer) I find this a bit odd. Isn't the idea of the primitive error handling that it is obvious and easy, as in "functions can return multiple results, a popular pattern is to return the good result and the error as two separate nullable values of which exactly one will be not null, so you can check if err == nil."? If you go with fancy error handling anyway, how is this '?' better than returning a…

The ? syntax agrees that errors should just be regular values returned from functions, and handling of errors should be locally explicit. It's not a different approach from `if err != nil return err`, it merely codifies the existing practice, and makes expressing the most common cases more convenient and clearer.

It's clearer because when you see ? you know it's returning the error in the standard way, and it can't be some subtly different variation (like checking err, but returning err2 or a non-nil ok value). The code around it also becomes clearer, because you can see the happy path that isn't chopped up by error branches, so you get high signal to noise ratio, fewer variables in the scope, without losing the error handling.

Re: Discussion: Reduce error handling boilerplate in Golang using '?'

#12

Post by pjmlp »

teeray wrote: post #4

I feel like error handling in Go is divided between people who have been using the language for a long time, and those who are new to it. If you're used to exceptions, and languages with some kind of '?' operator, typing `if err != nil` all the time is probably excruciating. They seem to be the most vocal in the survey about wanting beloved error handling features from their favorite languages. Once you've been using…

There are also those of us, old enough to have used Assembly as daily programming language, have used Go boilerplate style across many languages during 20+ years, and don't miss the days exceptions were still academic talk, unavailable in mainstream languages.

Re: Discussion: Reduce error handling boilerplate in Golang using '?'

#13

Post by 9rx »

cratermoon wrote: post #2

This is from Ian Lance Taylor, a major figure in the development of Go. Taylor was instrumental in bringing generics to the language, this proposal is worth taking seriously.

> Taylor was instrumental in bringing generics to the language, this proposal is worth taking seriously.

He submitted, what, 8 failed generics proposals before Phil Wadler came in to figure out what he was missing?

I don't mean to diminish what he has done. He is clearly an important contributor and even those failed proposals were important steps along the way. What I do mean is that judging a proposal based on who it is written by is silly. Imagine if one of those early generics proposals were taken seriously just because of who he is. I expect even he would be unhappy about that outcome in hindsight.

The author is irrelevant. If it is a good proposal, it can stand on its own merits.

Re: Discussion: Reduce error handling boilerplate in Golang using '?'

#14

Post by vrnvu »

Unfortunately, every software project will eventually reach a point of maturity where more and more features are added simply for the sake of adding them.

"The goal of this proposal is to introduce a new syntax that reduces the amount of code required to check errors in the normal case, without obscuring flow of control."

The key is "check errors in the normal case".

When the core principles of Go have always been simplicity, flexibility, and having one way of doing things, this feels completely like a step in the opposite direction. We will have syntax sugar for "normal cases" while still relying on the `if err != nil` block for everything else. It’s similar to how we now have both `iterators` and `for loops` as constructions for loops.

Re: Discussion: Reduce error handling boilerplate in Golang using '?'

#16

Post by madeofpalk »

teeray wrote: post #4

I feel like error handling in Go is divided between people who have been using the language for a long time, and those who are new to it. If you're used to exceptions, and languages with some kind of '?' operator, typing `if err != nil` all the time is probably excruciating. They seem to be the most vocal in the survey about wanting beloved error handling features from their favorite languages. Once you've been using…

I appreciate verbose and explicit patterns like this, but what go lacks is the algebraic data types/enum/unions to actually make this more ergonomic and checked.

I find it bizzare that go so strongly relies on this pattern, but lacks the features to make sure you actually check for errors.

Re: Discussion: Reduce error handling boilerplate in Golang using '?'

#18

Post by richbell »

teeray wrote: post #4

I feel like error handling in Go is divided between people who have been using the language for a long time, and those who are new to it. If you're used to exceptions, and languages with some kind of '?' operator, typing `if err != nil` all the time is probably excruciating. They seem to be the most vocal in the survey about wanting beloved error handling features from their favorite languages. Once you've been using…

> I feel like error handling in Go is divided between people who have been using the language for a long time, and those who are new to it. If you're used to exceptions, and languages with some kind of '?' operator, typing `if err != nil` all the time is probably excruciating. They seem to be the most vocal in the survey about wanting beloved error handling features from their favorite languages.

This implies that the only people who dislike Go's error handling are newbies that "don't get it".

Go's error handling is objectively bad for two reasons:

1. You are never forced to check or handle errors. It's easy to accidentally miss an `if err != nil` check, I've seen sages and newbies alike make this mistake.

> Errors in Go are right there, in your face, and undeniable that the operation you are doing can be faulty somehow.

2. Repeating `if err != nil` ad nauseam is not handling errors. Knowing the operation can be faulty somehow is a good way of putting it, because in most cases it's difficult — if not impossible — to figure out what specific failures may occur. This is exacerbated by the historical reliance on strings. e.g., Is it a simple issue that can be easily recovered? Is it a fatal error?

Re: Discussion: Reduce error handling boilerplate in Golang using '?'

#19

Post by floating-io »

The biggest issue I have with this proposal is that reading the code in naïve fashion comes up with the wrong answer for me; YMMV. The proposed form--

  foo ? { bar }
Reads naturally to me as "If foo then bar", when it's actually "If foo's error return exists then bar". I would suggest a different operator character, because this one reads wrongly IMO.

Maybe it's just because I originally come from C, where `foo ? bar : baz` meant "if foo then bar else baz", but the fact remains...

Re: Discussion: Reduce error handling boilerplate in Golang using '?'

#20

Post by thangngoc89 »

TriangleEdge wrote: post #15

Seems like the author assumes that only one error is returned. What if I want to return []error? What happens if my return objects are out of the normal order? Like F() (int, error, int) {...}. The proposal is nice, but a bit shallow.

> What happens if my return objects are out of the normal order? Like F() (int, error, int) {...}

The convention is that error should be the last return value. If the error is not nil, then discard other returned values.

Post reply on HN