Re: [lmi] Suppressing exception stack dumps

[Greg Chicares]

On 3/14/21 11:27 PM, Vadim Zeitlin wrote:
> 
>  The commit message of 12273527f (Add C++ exception unwinder for
> pc-linux-gnu, 2021-02-07) mentions that "practical experience will guide
> future use" and I'd like to provide some practical experience: IMHO, always
> getting dumps of all exceptions and the corresponding stack trace is not
> very useful, as it results in a huge amount of noise when running many
> tests.

I've found it annoying in unit tests, myself; but only there.

When I'm running a GTK build, my problem more often is finding the
backtrace among screensful of pink, yellow, and blue messages like:

(lmi_wx_shared:27528): Gtk-CRITICAL **: 11:51:49.031: 
gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkSpinButton
11:51:59: Debug: "Ctrl+Tab" is not supported as a keyboard accelerator with GTK
11:51:59: Debug: "Ctrl+Shift+Tab" is not supported as a keyboard accelerator 
with GTK
(lmi_wx_shared:27528): Gtk-WARNING **: 11:51:59.394: Drawing a gadget with 
negative dimensions. Did you forget to allocate a size? (node header owner 
GtkNotebook)

> [...] this should be done on demand and
> not on by default. Or, at the very least, there should be a way to turn
> this off.

Commit e0c15aab3 provides an on-off toggle, and toggles the backtrace
off in a handful of places where we know we don't want it.

> +    if (std::strcmp(std::getenv("LMI_VERBOSE_EXCEPTIONS"), "1") == 0)

That would offer much flexibility. But nothing else in lmi's C++ code
reads the environment (except getopt(), as I was surprised to find).
For pc-linux-gnu, it doesn't make much difference, but for msw, getenv()
it has some drawbacks:
 - it's inconvenient to set in an msw shortcut;
 - environment access may be blocked on corporate machines;
 - corporations might flag getenv() specifically as a "security" risk;
 - msw has traditionally limited the size of the total environment and
   of each string, and then altered the limits in OS updates;
so I'd rather sidestep all such potential problems by not using getenv()
at all.

Except in situations where lmi catches an exception and does something
interesting (e.g., displaying an abridged what() string), I usually want
to see a backtrace automatically. Restarting the program with a change
in its environment is less convenient--often, extremely less. And if I
don't want it, I just disregard it.