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

51–60 of 150 posts

Re: Go 1.13: xerrors

#51

Post by apta »

cle wrote: post #42
tylerhou wrote: post #39

Earlier quoted context omitted.

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

Go's error handling is essentially the same as Error/Either/StatusOr (returning errors as values). Re: exceptions, there are a lot of people, myself included, who do not view exceptions as "advancements", but as setbacks. Magically and suddenly subverting the normal control flow and unwinding the stack in highly concurrent programs (as is expected in Go) is an awful way to do error handling, and you end up having to…

> Go's error handling is essentially the same as Error/Either/StatusOr (returning errors as values).

Except that you cannot easily chain calls that return errors, or it isn't really that hard to accidentally ignore errors because of shadowing or overwriting the variable you're storing your errors in. Or the fact that using a union type to represent errors is a strictly superior way, both in terms of usability, as well as correctness. People should just face the fact that returning errors as a product type is a mistake.

> Magically and suddenly subverting the normal control flow and unwinding the stack in highly concurrent programs (as is expected in Go)...

You may want to see what approaches Akka or Erlang takes here. golang authors just decided to ignore established practices and use clunky approaches to problems that have already been solved.

Re: Go 1.13: xerrors

#52

Post by networkimprov »

tylerhou wrote: post #39
cle wrote: post #36

Earlier quoted context omitted.

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

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

Here is a menu of Requirements to Consider for Go 2 Error Handling.

The Go team's "Draft Design" (with check/handle keywords) somehow omitted a requirements section...

https://gist.github.com/networkimprov/961c9caa2631ad3b95413f...

Re: Go 1.13: xerrors

#53

Post by apta »

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?

One reason perhaps is that TypeScript took over that space, and TypeScript also came from a well known company.

Re: Go 1.13: xerrors

#54

Post by sansnomme »

apta wrote: post #47
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.

> I wonder if go came from somewhere not google- how would it fare. There was a precursor to golang that the some of the same authors worked on before they were at Google. It didn't go anywhere, precisely because it didn't have Google's name behind it.

I think it was called "C", by Bell Labs folks.

Re: Go 1.13: xerrors

#55

Post by grey-area »

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

So what would you do then?

If you don't like it, don't present pale echoes of criticisms we've already seen (not listening to 30 years of language design...), tell us what you would do instead, because the answer is non-obvious and there is no one 'right thing'.

Re: Go 1.13: xerrors

#56

Post by jrockway »

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

My takeaway from the last 30 years in computer science is that errors are not exceptional. They occur often and should be accounted for near the code that generates the errors.

Exceptions and return values are both sub-optimal. Exceptions encourage drastic actions for non-drastic events (exit the program if an HTTP server is transitently slow). Return values encourage ignoring the error value, and then wondering why your program broke. Special types that wrap error values or exceptions cause the same problem; when you want to defer something, your code becomes contaminated with the error type (f(x) returns an error, g(x) calls f(x) but doesn't feel like dealing with the erro, so now g(x) returns an error... and all the way it goes up to the top level.)

Overall, I don't see a grand unified solution to this problem. We should make it possible for functions to declare everything that goes wrong so that recovery can be more easily tested. No language does this; they often merge vastly different errors into the same type, so the programmer is powerless to understand the possibilities. Consider two database errors; "syntax error" and "transaction aborted, retry it". Typed error systems typically condense that to a "database error", but how your program should handle the two cases are vastly different.

Anyway, I'm happy with the way go works. If I don't explicitly know how to handle an error, I wrap it with a tag and return it. When I look at the alert / error logs, I know which codepath caused the problem and can investigate. For cases where I know how to handle an error, I can explicitly deal with it (yes, often with strings.HasSuffix to find the one I know how to handle). That is all I really need. If it were an exception, the code would be basically the same. So I think it's a red herring to complain about values vs. exceptions. Neither system prevents you or encourages you to write correct, robust code. If we want to do that, we need completely new tools.

Re: Go 1.13: xerrors

#57

Post by scrollaway »

BarkMore wrote: post #18
politician wrote: post #13

Earlier quoted context omitted.

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.

What's the point of making it a format string if you are hardcoding where the % identifier goes anyway?!

Re: Go 1.13: xerrors

#58

Post by whatupdave »

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.

Have to be careful here, this would send phone numbers into logs files and other potential downstream services which is a bit of a GDPR nightmare now.

Re: Go 1.13: xerrors

#59

Post by AsyncAwait »

apta wrote: post #45
pkaye wrote: post #41

Earlier quoted context omitted.

So what language do you think does everything the right way?

That's a stawman fallacy. There is no perfect language. However, there are languages that almost are strictly superior to others. Java and C# in this case are almost strictly superior to golang in almost every front.

Well, unless you consider Go's concurrency model superior, as well as the fact that you get native binaries.

Re: Go 1.13: xerrors

#60

Post by takeda »

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…

A bit offtopic how does pkg/errors compare to https://github.com/juju/errors/? I see the former is much more popular but the later seem to be nicer, I especially like the deferred annotations, since it's easy to use them to include function arguments in the stack trace.
Post reply on HN