Hi Jeremy, I really appreciate all the materials you have shared.
I could understand that wrapping errors with informative messages is one of
important best practice treating errors. I'll keep it mind that :)
It was also very helpful to read errors section in Effective Go which you
have shared
What's the current best practice for getting a stack trace from an error
passed up from further down in the stack?
E.g. a web server middleware uses recover to catch panics. In the recover,
we want the stack trace of the code that created the first error in the
stack.
On Monday, 3 February 202
I don't know if it qualifies as "best practice" but I think it would
certainly qualify as convention to put the error as the last returned
value. It is also extremely common to name the error "err", though that
would have little impact on API consumers as they can rename it whatever
they want.
