I understand that, I dont either. But what's the idea behind not having it at the first place? Is there more to it other than make it more simple?
On Fri, Sep 23, 2016, 8:29 AM Jan Mercl <0xj...@gmail.com> wrote: > 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.
