Comment 6 for bug 725349

On Mon, 2011-03-07 at 22:08 +0000, Soren Hansen wrote:
> If all you get in the log file is "An exception occurred" or perhaps "A
> KeyError exception occurred", I seriously doubt you'll be able to guess
> what triggered it so that you can reproduce it. Even with the stack
> trace, it can be hard enough.

I never said you only get "An exception occurred". The exception is
still printed out in its entirety; the only thing that's omitted is all
the lines that begin with "TRACE:" (or whatever you've configured). In
fact, the exception information ends up being printed twice,
currently--once as part of the ERROR message, then again at the end of
the TRACE, and its rendered identically in both places.

> Can you give me an example of a stack trace that you feel should be
> removed and what exactly you'd log instead?

See bug 715620. I cannot find a way to catch that exception without
either violating an abstraction boundary (trying to catch the specific
DB exception which itself isn't very specific) or casting far too wide a
net (catching a whole bunch of exceptions, some of which indicate
configuration problems for which a trace is noise, and some of which
could indicate software errors, for which a trace might be useful). My
patch corrects the issue, in that it prints out the exception message;
if the SQL connection can't be reached, that is easy to see.

> I actually think it's extremely useful to be able to leave out --verbose
> to avoid the debug information when everything is working fine, but
> still get the stack trace if something actually goes wrong.

To my mind, stack traces *are* debug information. We could add
--stacktraces/--nostacktraces, I suppose, but it would have to default
to being off...
--
Kevin L. Mitchell <email address hidden>