Nothing prevents you from including the call stack in the error message. Especially if you prefer the way how Java error messages look.
I don't. On Fri, Sep 23, 2016, 08:24 Yulrizka <yulri...@gmail.com> wrote: > 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. > -- -j -- 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.
