Bug #86185 for Mail-SPF: Using the "Error" module is no longer recommended

Sun Jun 16 13:01:16 2013 peter.baranyi [...] gmail.com - Ticket created

Subject:	Using the "Error" module is no longer recommended
Date:	Sun, 16 Jun 2013 13:00:45 -0400
To:	bug-Mail-SPF [...] rt.cpan.org
From:	Peter Baranyi <peter.baranyi [...] gmail.com>

Hi, if you check the Error module, it states at the beginning that Using the "Error" module is no longer recommended due to the black-magical nature of its syntactic sugar, which often tends to break. Its maintainers have stopped actively writing code that uses it, and discourage people from doing so. Please consider using something else. When I use Mail::SPF, I get multiple exceptions although everything is working fine. If I enable a simple die signal checking, $SIG{__DIE__} = sub { warn "Fatal exception\n"; }; I see the message printed 6 times! Unfortunately for me I am using the Carp module with cluck, and each time I would get like 20 pages of tracebacks for each exception! How can I avoid this, without disabling the die catch? I tried putting no Carp; where Mail::SPF is used but it helped only the first time and I get the same traceback for consecutive calls. regards, Peter

Message body is not shown because sender requested not to inline it.

Fri Oct 11 01:00:59 2013 JMEHNLE [...] cpan.org - Correspondence added

Perl's exception handling fundamentally relies on die'ing inside eval blocks. Any __DIE__ handlers will *always* be called for any exception raised, with or without use of the Error module, and even when the Perl process itself doesn't die: $ perl -e '$SIG{__DIE__} = sub { print("died.\n") }; die("FOO")' died. FOO at -e line 1. $ echo $? 255 $ perl -e '$SIG{__DIE__} = sub { print("died.\n") }; eval { die("FOO") }' died. $ echo $? 0 How this interferes with the use of the Carp module isn't clear to me. Can you clarify?

Fri Oct 11 01:00:59 2013 The RT System itself - Status changed from 'new' to 'open'

Fri Oct 11 01:15:47 2013 JMEHNLE [...] cpan.org - Correspondence added

http://stackoverflow.com/a/2168408/454126 points out that you can use $^S inside your __DIE__ handler to distinguish between an exception and a real "interpreter dying" situation.

Fri Oct 11 01:15:48 2013 JMEHNLE [...] cpan.org - Status changed from 'open' to 'rejected'

Wed Oct 16 20:59:11 2013 peter.baranyi [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #86185] Using the "Error" module is no longer recommended
Date:	Wed, 16 Oct 2013 20:58:31 -0400
To:	bug-Mail-SPF [...] rt.cpan.org
From:	Peter Baranyi <peter.baranyi [...] gmail.com>

The I mentioned the carp module because I get a huge trace for each exception which I don't want since as you point out, exceptions are normal. Thanks for the stackoverflow link, I'll try that. But forget about this, I wrote because the Error module is deprecated. On Fri, Oct 11, 2013 at 1:15 AM, Julian Mehnle via RT <bug-Mail-SPF@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=86185 > > > http://stackoverflow.com/a/2168408/454126 points out that you can use $^S inside your __DIE__ handler to distinguish between an exception and a real "interpreter dying" situation.

Wed Oct 16 21:24:09 2013 JMEHNLE [...] cpan.org - Correspondence added

On 2013-10-16 20:59:11, peter.baranyi@gmail.com wrote: Show quoted text

> But forget about this, I wrote because the Error module is deprecated.

Understood. However, Mail::SPF is existing code, and removing the use of Error.pm just because of its deprecation is likely not going to happen. I read about the issues of Error.pm, but Mail::SPF is not affected by any of them, so there is no pressing need for change. Wishlisting.

Wed Oct 16 21:24:10 2013 JMEHNLE [...] cpan.org - Status changed from 'rejected' to 'open'

Wed Oct 16 21:24:25 2013 JMEHNLE [...] cpan.org - Severity Wishlist added

Thu Feb 12 12:53:44 2015 quanah.gibsonmount [...] gmail.com - Correspondence added

On Wed Oct 16 21:24:09 2013, JMEHNLE wrote: Show quoted text

> Understood. However, Mail::SPF is existing code, and removing the use > of Error.pm just because of its deprecation is likely not going to > happen. I read about the issues of Error.pm, but Mail::SPF is not > affected by any of them, so there is no pressing need for change.

Relying on Error now causes other issues, because the author (maybe reasonably) does not want to address the various issues it has with building (such as relying on absurdly high versions of Module::Build, which pulls in a ton of dependencies when building on older Perl releases). For those of us doing builds of Mail::SPF for utilities such as SpamAssassin, and keeping our modules separate from system perl, being able to build Mail::SPF without having to rely on Error is extremely important. See https://rt.cpan.org/Ticket/Display.html?id=102062 for reference.