Should we stop using Carp::Always by default in the release version to reduce "noise"?

[Photon89]

Shutter has a --debug option, maybe we should use Carp::Always only if it is passed to reduce the amount of output during regular usage?

[Photon89]

log4perl has been proposed in a very old bug report, maybe still worth considering.

[DarthGandalf]

In normal execution, Carp::Always has no effect. It only adds more details if an exception is being thrown. The main increase of the noise comes from the lines like "Variable "%session_screens" will not stay shared at bin/shutter line 6997.", but those are not exceptions, so are written this way regardless of any Carp::Always.

It does increase the noise in cases like this:

GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/vendor_perl/5.32/x86_64-linux/Glib/Object/Introspection.pm line 110.
 at /usr/lib64/perl5/vendor_perl/5.32/Gtk3.pm line 489.
        Gtk3::import("Gtk3", "-init") called at bin/shutter line 72
        Shutter::App::BEGIN() called at bin/shutter line 72
        eval {...} called at bin/shutter line 72

Here, all lines except for the first one come from Carp::Always.

[Photon89]

Maybe it is possible to activate this additional output only if the --debug switch is used?

[DarthGandalf]

Options are parsed quite late there, after all the .pm files were evaluated.

[Photon89]

The main increase of the noise comes from the lines like "Variable "%session_screens" will not stay shared at bin/shutter line 6997.", but those are not exceptions, so are written this way regardless of any Carp::Always.

I wonder where those warnings came from. As far as I remember they were not there in versions prior to the GTK3 port but I'm pretty sure that the underlying problem was already there, it just became visible now. But how did it happen?

[DarthGandalf]

I think it comes from the time where I had to switch from Gtk2::Unique to Gtk3::Application which has different API, so I had to move some functions around. Maybe eventually @ruzhnikov finishes his refactoring to classes which should make everything clearer, and not rely anymore on a bunch of variables which are essentially global but not even declared as such.