3 ms·
At $DAYJOB we had a Go dependency on a package (maybe pkg/sftp?) that used github.com/pkg/errors to capture a stack trace with the error. These errors were ulti
by mappu 5y ago
At $DAYJOB we had a Go dependency on a package (maybe pkg/sftp?) that used github.com/pkg/errors to capture a stack trace with the error. These errors were ultimately used in a loop for flow control (maybe testing a lot of files/servers?) where collecting all the stack traces caused a lot of slowdown, heap garbage, and GC pressure.
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.
- xyzzy_plugh 5y agoYes, 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.
- derekperkins 5y agoInsane overhead in what way?
- Abishek_Muthian 5y ago> 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.
- gregwebs 5y agoI 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 https://github.com/pingcap/errcode