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

Go 1.13: xerrors

crawshaw.io

Post reply on HN
Print view View original

11–20 of 150 posts

Re: Go 1.13: xerrors

#11

Post by jerf »

albeebe1 wrote: post #2

Speaking of errors, here's how i approach writing a good error message. Fill in the blank "Well basically what happened is ___________" For example i've found this has helped me to go from "Invalid phone number" to "The phone number needs to be 10 digits"

One of the things I picked up from Dave Winer around 20 years ago is that errors messages should be of the form "Can't X because Y", and while I don't quite always use that exact grammar form, my errors pretty much all take that form when there isn't some other overriding local standard for errors. It's not a bad template. Most error messages will give you some hint about the Y, but the difference between "Error: file system full" and "Error: couldn't open log file '/var/log/myapp.log' because: file system full" is pretty substantial, especially if system state has mutated in the meantime and by the time you get to the system, none of the filesystems are full anymore.

Re: Go 1.13: xerrors

#12

Post by trpc »

It seems like golang designers are totally isolated from what's been happening in the last 30 years in languages design. They still insist on their weird way of error handling just like they were stubborn for years and years on the lack of package management and eventually a very weird and rudimentary way of it. It's sad because I use this language extensively but its weirdly mediocre design is totally unfathomable. It's like they are very stubborn to do anything but the right thing.

Re: Go 1.13: xerrors

#13

Post by politician »

nickcw wrote: post #4

This (it looks like to me) is an attempt to pull in the best bits of Dave Cheney's errors package (which I love) into the standard library: https://github.com/pkg/errors Standardising error unwrapping is a great idea IMHO and I think that this has a lot of merit. I don't like the `fmt.Errorf("more description: %w", err)` though for several reasons. Firstly it is a lot more opaque than Dave Cheney's original mechanism…

Also note that the library checks for `: %w` at the end of the format string to enable this wrapping feature. If you use "%w" anywhere else in the format string it won't work.

Yuck.

Re: Go 1.13: xerrors

#14

Post by icholy »

trpc wrote: post #12

It seems like golang designers are totally isolated from what's been happening in the last 30 years in languages design. They still insist on their weird way of error handling just like they were stubborn for years and years on the lack of package management and eventually a very weird and rudimentary way of it. It's sad because I use this language extensively but its weirdly mediocre design is totally unfathomable.…

> I use this language extensively but its weirdly mediocre design is totally unfathomable.

So then why do you use it extensively?

Re: Go 1.13: xerrors

#15

Post by icholy »

politician wrote: post #13
nickcw wrote: post #4

This (it looks like to me) is an attempt to pull in the best bits of Dave Cheney's errors package (which I love) into the standard library: https://github.com/pkg/errors Standardising error unwrapping is a great idea IMHO and I think that this has a lot of merit. I don't like the `fmt.Errorf("more description: %w", err)` though for several reasons. Firstly it is a lot more opaque than Dave Cheney's original mechanism…

Also note that the library checks for `: %w` at the end of the format string to enable this wrapping feature. If you use "%w" anywhere else in the format string it won't work. Yuck.

Yeah, that's the only thing I don't like about this proposal. Just seems so fragile.

Re: Go 1.13: xerrors

#16

Post by trpc »

icholy wrote: post #14
trpc wrote: post #12

It seems like golang designers are totally isolated from what's been happening in the last 30 years in languages design. They still insist on their weird way of error handling just like they were stubborn for years and years on the lack of package management and eventually a very weird and rudimentary way of it. It's sad because I use this language extensively but its weirdly mediocre design is totally unfathomable.…

> I use this language extensively but its weirdly mediocre design is totally unfathomable. So then why do you use it extensively?

because I use it in my day job, not by choice.

Re: Go 1.13: xerrors

#17

Post by smudgymcscmudge »

jerf wrote: post #10
binwiederhier wrote: post #9

As others have stated, this seems incredibly odd to me: > If the last argument is an error and the format string ends with ": %w", ... This seems like a magic-string kinda hack to me. I like the idea of wrapping errors so that you keep the stack and full context, especially since you may need additional structured data from all errors (e.g. DB error, access error, ...) to produce user facing messages, so IMHO the wra…

It is. It's a backwards-compatibility magic string hack. I would suggest new code uses the new, formal ways of obtaining the same result. (I'm not defending it so much as explaining it. I'm not sure how I feel about it myself.)

> I would suggest new code uses the new, formal ways of obtaining the same result

I missed that. How else do you wrap an error with xerrors?

Re: Go 1.13: xerrors

#18

Post by BarkMore »

politician wrote: post #13
nickcw wrote: post #4

This (it looks like to me) is an attempt to pull in the best bits of Dave Cheney's errors package (which I love) into the standard library: https://github.com/pkg/errors Standardising error unwrapping is a great idea IMHO and I think that this has a lot of merit. I don't like the `fmt.Errorf("more description: %w", err)` though for several reasons. Firstly it is a lot more opaque than Dave Cheney's original mechanism…

Also note that the library checks for `: %w` at the end of the format string to enable this wrapping feature. If you use "%w" anywhere else in the format string it won't work. Yuck.

The go vet command checks format strings. I expect that the command will be updated to check for correct use of %w.

Re: Go 1.13: xerrors

#19

Post by llimllib »

smudgymcscmudge wrote: post #17
jerf wrote: post #10

Earlier quoted context omitted.

It is. It's a backwards-compatibility magic string hack. I would suggest new code uses the new, formal ways of obtaining the same result. (I'm not defending it so much as explaining it. I'm not sure how I feel about it myself.)

> I would suggest new code uses the new, formal ways of obtaining the same result I missed that. How else do you wrap an error with xerrors?

    return errors.Wrap(err, "read failed")

Re: Go 1.13: xerrors

#20

Post by fxfan »

trpc wrote: post #12

It seems like golang designers are totally isolated from what's been happening in the last 30 years in languages design. They still insist on their weird way of error handling just like they were stubborn for years and years on the lack of package management and eventually a very weird and rudimentary way of it. It's sad because I use this language extensively but its weirdly mediocre design is totally unfathomable.…

I've heard great points and experienced myself how utterly legible go is. But nobody on earth has ever praised anything about the language design itself. I wonder if go came from somewhere not google- how would it fare.
Post reply on HN