Hacker News Reader

Yes, I've gone back and forth on "all errors should be annotated" or "all errors should have a full stack trace" and frankly, I'm now in the "it's just an error" camp. Stack traces seem great but are kinda insane overhead. If you're bubbling up errors from a real deep place, having a $package.$method: %w wrap the error is nice, but beyond that, it's a headache.

Insane overhead in what way?

I believe the solution to this is to classify errors properly. Any "internal error" as in HTTP 500 Internal Error should be generating a stack trace. Most other expected errors (like your case) should not. I codified this practice in a library I created for Go called errcode [1] which is designed to attach error codes and other meta information where errors are generated.

[1] https://github.com/pingcap/errcode

> I used go mod replace to strip the stack trace collection out of pkg/errors, with a fork that does a no-op for that function call, and it was a significant improvement for our use case.

Is there a write-up or references on how one can achieve this? Sounds like a good practical use case for the replace directive.