Proposal: output stack trace if debugging is enabled about errors

[cyphar]

#97 is my implementation of this.

[davecheney]

Thank you for your suggestion. As presented I'm not keen on adding this because it overides the choice of code that prints the error. Can you tell me more about your requirements, why do you need to add this option, how are errors not being presented in a way that isnt useful for you. There's also th issue of this being a global flag, which is hard for everyone to test.

…

On Fri, 16 Dec 2016, 20:31 Aleksa Sarai ***@***.***> wrote: #96 <#96> is my implementation of this. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#96 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcAzX0phz4a_lG1b3LqB5gKOexR4s2ks5rIlp7gaJpZM4LO74v> .

[cyphar]

Thank you for your suggestion. As presented I'm not keen on adding this because it overides the choice of code that prints the error. Can you tell me more about your requirements, why do you need to add this option, how are errors not being presented in a way that isnt useful for you.

Let's say that I'm messing around with a program I've written, and I want to figure out why I'm getting a particular error. I'm using pkg/errors, so I know that the stack trace is stored in the error. However, I don't want to have to modify the code and then recompile it in order to figure out what the stack trace is (this is software which has already been packaged and I've just downloaded the binary). The program has a --debug flag but it only gives me log output that is not very useful. Unfortunately for the author (me), there is no easy way to make my --debug flag also output the stack trace. I might have multiple CLI endpoints or different logging endpoints that print the errors -- and I want the stacktrace to be written to *all* of them. logrus has logrus.LogLevel(...) which lets you set the global logging level of the program. Why not include the same feature to pkg/errors?

There's also th issue of this being a global flag, which is hard for everyone to test.

But good libraries shouldn't be printing errors to anywhere -- they should just be wrapping and returning them. Plus, if they just want a string output they can still use %s if you look at my patch[1]. The main point of this is so that I can actually make it possible for users of my program to provide me a stack trace of the issue, rather than saying "hey, can you please modify line XYZ of SOURCE.go and then recompile it, and then tell me what error you get now". Also, I have added tests to my PR[1]. But are you saying that you think that it would be hard for someone to check whether the debug flag is set? How does logrus handle this -- maybe we can take a page from their book. [1]: #97

…

-- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/

[loren-osborn]

@davecheney, I’m mostly thinking out loud here, and haven’t thought as far as an API yet, but I’m wondering if a cascading priority makes sense:

• If the caller chooses to render the error with or without a stack trace explicitly, that is always honored.
• If the caller uses default error rendering, but the error itself (based on options when the error was created) prefers to be rendered with or without a stack trace explicitly, that is how the error is rendered.
• If neither the caller nor the error specify if they want a stack trace, a global default, (similar to #96 / #97) determines if the error renders a stack trace.

As I indicated above, these are just ideas I had reviewing old PRs. I’d be interested to hear your opinions.

[davecheney]

Thank you for your comment. My position has not changed since my last comment.

[cyphar]

Within umoci I've just decided to use %+v if debugging is enabled. This works for me since everything goes through a single CLI library, but maybe others want this. Closing.