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

31–40 of 150 posts

Re: Go 1.13: xerrors

#31

Post by masklinn »

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

> Secondly why is this really important functionality in `fmt` and not in `error`? `fmt` already depends on `errors`, and Go does not allow cyclical dependencies, so `errors` would have to reimplement string formatting.

Or they could move the machinery into a shared module.

Which already exists incidentally, internal/errinternal was added so errors.New and fmt.Errorf could return the same type.

It does make errors pull the entire formatting machinery, but chances are you're probably using string formatting long before errors so meh…

Re: Go 1.13: xerrors

#32

Post by masklinn »

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.)

Backwards compatibility with what? You have to change the code to do anything new, that change could be using a different function entirely.

Re: Go 1.13: xerrors

#33

Post by jagger27 »

richardwhiuk wrote: post #27
_ph_ wrote: post #23

Earlier quoted context omitted.

And I am so happy that they won't do anything but the right thing. Over the decades as a programmer I have seen a lot of language come and go. A lot of languages suffer from "features". Where either a language is designed with advanced concepts getting either directly in the way of writing simple programs, or even worse, getting bolted on later on, creating something very different from the initial language. I love t…

> And I am so happy that they won't do anything but the right thing. That's clearly not true - they've made plenty of mistakes.

The only big one that comes to mind is GOPATH. What are you thinking of?

Re: Go 1.13: xerrors

#34

Post by skybrian »

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…

Yes, it's a magic string hack. On the other hand, it's concise and easily learned. This is kind of the opposite of the "if err!=nil" dance that many people complain about.

I expect we will get used to it pretty quickly.

Re: Go 1.13: xerrors

#35

Post by mattnewton »

spullara wrote: post #21
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"

The biggest issue I have with most error messages is that they say things like you have here but don't reflect back the data that caused the error, i.e. show me the phone number you think I sent you.

I think this context is really hard to carry around, and if you aren’t extra super careful you can end up leaking passwords and other secret bits of memory here to logs. Better to just give me a place to put a debugger breakpoint IMO.

Re: Go 1.13: xerrors

#36

Post by cle »

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.…

Can you elaborate on the major developments in error handling in the last 30 years?

Re: Go 1.13: xerrors

#37

Post by aikah »

icholy wrote: post #24
fxfan wrote: post #20

Earlier quoted context omitted.

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.

Dart also came from Google. Why isn't everyone jumping on that train?

Dart was born "for the wrong reasons" AKA replacing Javascript, it failed at it. The language itself is quite good, better than Go IMHO, but Go has the advantage of not requiring a separate virtual machine. The problem with languages is whether they get enough momentum so that a community can be built around them. A language without an extensive ecosystem is nothing.

Also since Go is "hypocritically Object Oriented", people can claim it's not an object oriented language and kind of write Go like classic structured programming such as C. But Go is OO. You can't write go without using interfaces for I/O.

Re: Go 1.13: xerrors

#38

Post by [deleted] »

masklinn wrote: post #32
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.)

Backwards compatibility with what? You have to change the code to do anything new, that change could be using a different function entirely.

[deleted]

Re: Go 1.13: xerrors

#39

Post by tylerhou »

cle wrote: post #36
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.…

Can you elaborate on the major developments in error handling in the last 30 years?

I assume exceptions, the Error/Either monad, and StatusOr.

Re: Go 1.13: xerrors

#40

Post by ChrisSD »

skybrian wrote: post #28
icholy wrote: post #24

Earlier quoted context omitted.

Dart also came from Google. Why isn't everyone jumping on that train?

It's kind of irrelevant since it's a different team with a different software niche and design aesthetic, but since you ask: Dart struggled for years to find a killer app, though Flutter now seems to be a good bet. Originally the idea was to replace JavaScript and everyone except TypeScript pretty much failed at that. (I mean failed from a popularity point of view, they often succeeded technically.) I'll also point o…

It should be noted that TypeScript succeed by augmenting Javascript, instead of strictly replacing it as most other languages tried to do.
Post reply on HN