Skip Menu |
 

This queue is for tickets about the Mail-SPF CPAN distribution.

Report information
The Basics
Id: 86185
Status: open
Priority: 0/
Queue: Mail-SPF

People
Owner: Nobody in particular
Requestors: peter.baranyi [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)



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>
Download (untitled) / with headers
text/plain 900b
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
Download spf.pl
text/x-perl 963b

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

Download (untitled) / with headers
text/plain 530b
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?
Download (untitled) / with headers
text/plain 179b
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.
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>
Download (untitled) / with headers
text/plain 598b
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.
Download (untitled) / with headers
text/plain 413b
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.
Download (untitled) / with headers
text/plain 893b
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.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.