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

61–70 of 94 posts

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

#61

Post by teeray »

memset wrote: post #7
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…

Super interested in your approach to error wrapping! It’s a feature I haven’t used much. I tend to use logs with line numbers to point to where errors occur (but that only gets me so far if I’m returning the error from a child function in the call stack.)

Simply wrap with what you were trying to do when the error occurred (and only that, no speculating what the error could be or indicate). If you do this down the call stack, you end up with a progressive chain of detail with strings you can grep for. For example, something like "processing users index: listing users: consulting redis cache: no route to host" is great. Just use `fmt.Errorf("some wrapping: %w", err)` the whole way up. It has all the detail you want with none of the detail you don't need.

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

#62

Post by plorkyeran »

zemo wrote: post #47
floating-io wrote: post #19

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…

Go doesn't have a ? operator today, and the ? operator being used for error handling has precedence in Rust and Zig, so it doesn't seem to be all that out of the ordinary or without precedent in other languages.

The proposed behavior is the opposite of how Swift and Rust use ?. `foo?.bar()` invokes `foo.bar()` in the non-error case, while in Go `foo ? { bar() }` invokes it in the error case.

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

#63

Post by cratermoon »

9rx wrote: post #13
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…

Thanks for your insights, they are both penetrating and diffuse.

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

#64

Post by 9rx »

jayd16 wrote: post #54
nonethewiser wrote: post #43

Earlier quoted context omitted.

This is probably the one that would anger Golangers the most lol

They could even have typed error checking for different errors and an automatic return error syntax. { Foo } catch (err) {} catch (err2){} throw

Agreed. The reduction in boilerplate to route error conditions is what we really need, if we are going to add any special error concept. errors.Is/errors.As and the accompanying switch/if statements can quickly consume entire screens of code for all but the most simplest of failure cases and as a result it often sees developers become lazy and just return err instead.

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

#65

Post by new_user_final »

Swizec wrote: post #8
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…

Where I've found `?` super helpful in JS/TS and now miss it the most in Python is dealing with nested data structures. ``` if (foo.bar?.baz?.[5]?.bazinga?.value) ``` Is so much nicer than ``` if foo.bar and foo.bar.baz and foo.bar.baz[5] and foo.bar.baz[5].bazinga and foo.bar.baz[5].bazinga.value ``` I honestly don't care which one of those is falsy, my logic is the same either way. This enables you to ergonomically…

You can use following syntax in python, ugly but better than multiple and (I don't use python anymore)

    if dict.get('key', {}).get('key-nested',{}).get....:

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

#66

Post by new_user_final »

nonethewiser wrote: post #49
Swizec wrote: post #8

Earlier quoted context omitted.

Where I've found `?` super helpful in JS/TS and now miss it the most in Python is dealing with nested data structures. ``` if (foo.bar?.baz?.[5]?.bazinga?.value) ``` Is so much nicer than ``` if foo.bar and foo.bar.baz and foo.bar.baz[5] and foo.bar.baz[5].bazinga and foo.bar.baz[5].bazinga.value ``` I honestly don't care which one of those is falsy, my logic is the same either way. This enables you to ergonomically…

Yes, same experience. As someone who learned on python then got deep into Typsecript, this was a major bummer when returning to python. Its funny because when I was a beginner in both I strongly preferred python syntax. I thought it was much simpler.

As I have pointed in in my other comment, you can use following syntax in python, ugly but better than multiple and (I don't use python anymore)

    if dict.get('key', {}).get('key-nested',{}).get....:

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

#67

Post by 9rx »

madeofpalk wrote: post #59
nonethewiser wrote: post #45

Earlier quoted context omitted.

Im not really following this. Only somewhat familiar with Go. The pattern we're talking about is returning errors and having to explicitly check for them, right? How does the lack of "algebraic data types/enum/unions" make this pattern un-ergonomic?

Error patterns aren't type checked in Go. So you can forget to check an error, not notice, and ship a bug. It compounds with features like zero values and pointers-as-null to make these bugs either subtle or not subtle, but discoverable only at runtime.

> So you can forget to check an error, not notice, and ship a bug.

How would you forget, exactly? Your tests are going to blow in your face should you ever leave out an entire feature from the implementation.

If you forgot to document that feature in your tests, which is more likely, then you've created a situation of undefined behaviour, not a bug. You've made no claims as to what should happen. All possible behaviours are equally valid.

And no, pattern matching doesn't help you here as you still need to document what happens on those pattern matches. If you forget to document these cases you've still got the very same undefined behaviour. There is no escaping the need for the tests.

It's cool that there is nicer syntax, that your editor can warn you of mistakes while you are typing, and that can save time and all that don't get me wrong, but this idea that you are going straight up forget without any notice of your forgetfulness, as fun as a trope as it is, just isn't realistic.

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

#68

Post by toxik »

floating-io wrote: post #19

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…

  foo else { bar }

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

#69

Post by richbell »

9rx wrote: post #67
madeofpalk wrote: post #59

Earlier quoted context omitted.

Error patterns aren't type checked in Go. So you can forget to check an error, not notice, and ship a bug. It compounds with features like zero values and pointers-as-null to make these bugs either subtle or not subtle, but discoverable only at runtime.

> So you can forget to check an error, not notice, and ship a bug. How would you forget, exactly? Your tests are going to blow in your face should you ever leave out an entire feature from the implementation. If you forgot to document that feature in your tests, which is more likely, then you've created a situation of undefined behaviour, not a bug. You've made no claims as to what should happen. All possible behavio…

> How would you forget, exactly? Your tests are going to blow in your face should you ever leave out an entire feature from the implementation.

> ... this idea that you are going straight up forget without any notice of your forgetfulness, as fun as a trope as it is, just isn't realistic.

By forgetting. Copying `if err != nil` is a mundane and repetitive process, it's easy for your brain to go into auto-pilot.

> And no, pattern matching doesn't help you here as you still need to document what happens on those pattern matches. If you forget to document these cases you've still got the very same undefined behaviour. There is no escaping the need for the tests.

Pattern matching (with algebraic data types/enum/unions) helps because it forces you to check the error. It becomes impossible to use a return value without checking the error.

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

#70

Post by toxik »

teeray wrote: post #61
memset wrote: post #7

Earlier quoted context omitted.

Super interested in your approach to error wrapping! It’s a feature I haven’t used much. I tend to use logs with line numbers to point to where errors occur (but that only gets me so far if I’m returning the error from a child function in the call stack.)

Simply wrap with what you were trying to do when the error occurred (and only that, no speculating what the error could be or indicate). If you do this down the call stack, you end up with a progressive chain of detail with strings you can grep for. For example, something like "processing users index: listing users: consulting redis cache: no route to host" is great. Just use `fmt.Errorf("some wrapping: %w", err)` th…

So hand rolled call stack traces? I just don’t understand why this is better than exceptions.
Post reply on HN