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

Structured Errors in Go (2022)

southcla.ws

Post reply on HN
Print view View original

31–40 of 75 posts

Re: Structured Errors in Go (2022)

#31

Post by radlad »

atombender wrote: post #24
masklinn wrote: post #23

Earlier quoted context omitted.

This is covered by the “ergonomics” section of TFA: > With custom error structs however, it's a lot of writing to create your own error type and thus it becomes more of a burden to encourage your team members to do this. Because you need a type per layer, and that type needs to implement both error and unwrap.

In practice, I have found the benefit of explicit typing to outweigh the downsides of needing to declare the types. As a concrete example, it means you can target types with precision in the API layer: switch e := err.(type) { case UserNotFound: writeJSONResponse(w, 404, "User not found") case interface { Timeout() bool }: if e.Timeout() { writeJSONResponse(w, 503, "Timeout") } } I skimmed the article and didn't see…

You can also just assign your errors to variables, and typically you only need to do so for the innermost error. Wrapping calls can just use Errorf with the %w operator.

Horses for courses.

Re: Structured Errors in Go (2022)

#32

Post by pjmlp »

candiddevmike wrote: post #30
pjmlp wrote: post #13

Earlier quoted context omitted.

Go itself is wonky, yet another programming language that is a fine example of worse is better mentality in the industry, whose adoption was helped by having critical infrastructure software written in it.

> whose adoption was helped by having critical infrastructure software written in it Doesn't this contradict the first part of your post? Kubernetes for instance was ported from Java to Go (albeit, poorly). Is Java worse than Go?

Java is too advanced for Go folks, it is a PhD level language, when compared with Go minimalism, and their disdain for modern type systems (modern as in, invented in 1976, e.g. CLU and ML).

Also it is quite ironic how given the Java bashing on Go community, there was so little learned from Java evolution and design mistakes.

They even ended up having to reach for the same folks that helped designing Java generics.

As for your remark, the actual rewrite history as told at FOSDEM, is that the rewrite only happened as two strong minded Go devs joined the Kubernetes team and heavily pushed for the rewrite.

Re: Structured Errors in Go (2022)

#33

Post by [deleted] »

masklinn wrote: post #15
j1elo wrote: post #9

Earlier quoted context omitted.

I think this is the way to bubble up error messages that I like the most. Simple, not needing any additional tools, and very practical (sometimes even better than a stack trace). The idea is to only add information that the caller isn't already aware of . Error messages shouldn't include the function name or any of its arguments, because the caller will include those in its own wrapping of that error. This is done wi…

> This message shows at a quick glance which participant, which database selection, and which integer value where used when the call failed. And it's completely useless for looking up the errors linked to a participant in an aggregator, which is pretty much the first issue the article talks about, unless you add an entire parsing and extraction layer overtop. > Much more useful than Stack Traces, which don't show arg…

[deleted]

Re: Structured Errors in Go (2022)

#36

Post by [deleted] »

RadiozRadioz wrote: post #5

These are good general tips applicable to other languages too. I strongly dislike when code returns errors as arbitrary strings rather than classes, as it makes errors extremely difficult to handle; one would presumably want to handle a http 502 diffrernetly to a 404, but if a programmer returns that in a string, I have to do some wonky regex instead of checking the type of error class (or pulling a property from an…

[deleted]

Re: Structured Errors in Go (2022)

#37

Post by pstuart »

porjo wrote: post #11
weakfish wrote: post #8

Not a Go engineer but Go-curious - shouldn’t this use slog[0] for structured logging rather than a third party?

The article is from 2022 which predates slog in stdlib. Article also references Wrap() & Wrapf() which are also not part of stdlib (odd they don't mention that imo).

It was likely using the previous default error lib github.com/pkg/errors

Re: Structured Errors in Go (2022)

#38

Post by mirekrusin »

maccard wrote: post #14
mirekrusin wrote: post #12

Earlier quoted context omitted.

I think what you want are not dedicated classes but error codes. If you find yourself needing to branch on error classes it may mean error handling is too high up. ps. personally I always prefer string error codes, ie. "not-found" as opposed to numeric ones ie. 404.

Agree on error codes, but I disagree on branching. An api request failing with 429 is retry able (after a period), but a 401 isn’t. A 401 might require a refreshing an authorisation token, but a 400 maybe needs the user to change their input. > I always prefer string error codes My parent company provides an API for us to use for “admin-y” things, but they use stringy errors in the response payload of the body. Excep…

I didn't say not to branch on error code.

Error _code_ is code, shouldn't be localized.

Re: Structured Errors in Go (2022)

#40

Post by jamesrr39 »

pjmlp wrote: post #32
candiddevmike wrote: post #30

Earlier quoted context omitted.

> whose adoption was helped by having critical infrastructure software written in it Doesn't this contradict the first part of your post? Kubernetes for instance was ported from Java to Go (albeit, poorly). Is Java worse than Go?

Java is too advanced for Go folks, it is a PhD level language, when compared with Go minimalism, and their disdain for modern type systems (modern as in, invented in 1976, e.g. CLU and ML). Also it is quite ironic how given the Java bashing on Go community, there was so little learned from Java evolution and design mistakes. They even ended up having to reach for the same folks that helped designing Java generics. As…

Hmm, many people writing Java without a PhD...
Post reply on HN