This repository has been archived by the owner on Dec 1, 2021. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 696
Proposal: output stack trace if debugging is enabled #96
Comments
#97 is my implementation of this. |
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>
.
|
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/
|
@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:
As I indicated above, these are just ideas I had reviewing old PRs. I’d be interested to hear your opinions. |
Thank you for your comment. My position has not changed since my last comment. |
Within |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
In other words, it should be possible for a user at runtime to provide a
--debug
flag to a binary and then the binary should be able to easily make any error output a stack trace.The nicest way of doing this (IMO) would be to have something like
logrus.LogLevel
(except it would be something likeerrors.EmitStack(bool)
that would determine whether"%s"
and similar format strings will output a stack trace.Currently an application writer has to make a decision whether they will make their program debuggable (use
%+v
everywhere) or helpful to users (use%s
everywhere).The text was updated successfully, but these errors were encountered: