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? Thanks -- 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.
