2016. szeptember 23., péntek 8:23:58 UTC+2 időpontban Yulrizka a következőt írta: > > Hello > > I was watching Dave Cheney's presentation in gopher conf and was > fascinated. > > (btw he also wrote a blog post here > http://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully > ) > > In some case, I can relate. For example when I'm working on quite large > codebase, Sometimes I found errors like > > "failed X: io.EOF" and the caller was about 5 level deep. That doesn't > help and sometimes it require me to trace the code. > > Sometimes we also wrap the error message to give more context such as: > > " Failed updating x: Failed processing feed: XML lint error: failed > getting XML: timed out" > > But still, sometimes this require me to trace the full stack to find out > where it was generated. > > Which got me to think, what was the design philosophy behind the error > interface? > why is there only a string and no call stack? > How do you usually structure code so that the error message is then > meaningful? >
I use github.com/pkg/errors and print it with "%+v" if needed. It includes a stack trace, wraps errors nicely, and keeps the original location, too. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
