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

Show HN: Error return traces for Go, inspired by Zig

github.com

Post reply on HN
Print view View original

11–20 of 92 posts

Re: Show HN: Error return traces for Go, inspired by Zig

#11

Post by Groxx »

oefrha wrote: post #9
Groxx wrote: post #7

Earlier quoted context omitted.

At the very least: > This repository has been archived by the owner on Dec 1, 2021. It is now read-only. It's largely complete so it is essentially fine at the moment, but it won't be adapted to future language or community changes. A future landmine.

It’s archived mainly because it’s been superseded by fmt.Errorf() with the %w directive. Go 1.20 also introduced errors.Join() and multi-%w which github.com/pkg/errors lack, so using for green field projects is very ill-advised.

Except for the stack trace part, which is a gigantic reason why it was popular.

tbh I'm not sure what the current popular option is for wrapping with stack traces.

Re join: it isn't a joiner-error, it has no need to do anything for that. Just stdlib-join-then-wrap.

Re: Show HN: Error return traces for Go, inspired by Zig

#15

Post by pixelpoet »

(Aside about Zig, sorry. Although this applies to Go as well, I think?) Urgh I am so keen to switch to Zig but their attitude towards having vector operators just completely kills the viability for me as a graphics programmer.

I've asked in their Discord, Andrew Kelley himself passed on commenting (I know his stance, every C++ dev wants their fav feature), but the reality remains that it's just infeasible to do with a DSL so it's just the wrong language for writing graphics code.

Re: Show HN: Error return traces for Go, inspired by Zig

#16

Post by avg_dev »

abhinavg wrote: post #6
Eun wrote: post #4

Can you explain why we should this over https://github.com/pkg/errors ?

The README covers the idea behind errtrace in more details, but the primary difference is in what is captured: pkg/errors captures a stack trace of when the error occurred, and attaches it to the error. This information doesn't change as the error moves through the program. errtrace captures a 'return trace'--every 'return' statement that the error passes through. This information is appended to at each return site.…

How does one go about implementing something like this? I am quite curious.

Re: Show HN: Error return traces for Go, inspired by Zig

#17

Post by Vanclief »

While from a first instance, this package seems a bit overkill, I think the idea is interesting and is something that can be improved for Go.

I also felt that Go errors where too bare-bones, so I developed a small package (https://github.com/Vanclief/ez) based on an awesome post that I saw here once. I use this package in all Golang code I touch.

Re: Show HN: Error return traces for Go, inspired by Zig

#18

Post by kaba0 »

packetlost wrote: post #10
kaba0 wrote: post #8

[flagged]

Exceptions are only better than C style error return numbers but worse than pretty much every other model of error handling we have today.

Based on what exactly? I do think that e.g. rust’s error handling is quite okay with proper algebraic data types, but (checked) exceptions are similarly safe and ergonomic to use. The worst is without doubt the C style, whose legacy Go happily lengthens by doing the exact same thing, but natively in the language.

Re: Show HN: Error return traces for Go, inspired by Zig

#20

Post by yalue »

avg_dev wrote: post #16
abhinavg wrote: post #6

Earlier quoted context omitted.

The README covers the idea behind errtrace in more details, but the primary difference is in what is captured: pkg/errors captures a stack trace of when the error occurred, and attaches it to the error. This information doesn't change as the error moves through the program. errtrace captures a 'return trace'--every 'return' statement that the error passes through. This information is appended to at each return site.…

How does one go about implementing something like this? I am quite curious.

Judging by the project, it's implemented by instrumenting the source code; either manually modifying error returns with a wrapper function, or by running source files through an automated tool that will find and modify the return statements for you.
Post reply on HN