Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

$@ gets set differently on eval and Log::Dispatch::Email

by Pickwick (Beadle)
on Aug 12, 2013 at 11:02 UTC ( [id://1049105]=perlquestion: print w/replies, xml ) Need Help??

Pickwick has asked for the wisdom of the Perl Monks concerning the following question:

Dear Monks,

I use Log4perl in one of my applications and created my own appender which inherits from Log::Dispatch::Email because I need some special handling of sendmail. This appender worked for some years now, but today I recognized some weird behavior in which $@ doesn't get set as before if I configure Log4perl to use my appender or simply Log::Dispatch::Email itself. I used to catch errors in the following way:

eval { main(); 1; }; if (my $error = $@) { log()->error($error); exit(error_no_success()); } exit(error_success());

If I remove the mail appender from my Log4perl configuration and my application dies in main, $error gets the message and it gets logged within the alternative. The problem now is that when I configure my own descendant of Log::Dispatch::Email or this abstract base class directly, $@ in the above statement is the empty string, resulting in the same error as before isn't recognized anymore. If I write something like "eval {} or ..." $@ is properly available and can be saved. The following works:

my $error = undef; eval { main(); 1; } or $error = $@; my $error2 = $@; if ($error) { log()->error($error); exit(error_no_success()); } exit(error_success());

$error2 is always the empty string if I configure Log::Dispatch::Email in any way. Of course I don't want to change all my code which uses the first example and used to work before to the second one.

Is there anything wrong with my first example? From my point of view it looks like documented for eval in perldoc and it works without email appenders.

Can you think of any reason why using mail appenders changes the behavior on how or when or whatever Perl sets $@ in my second example? Any workarounds? I already had a look at the sources of Log::Dispatch but couldn't find anything obviously interfering with my code.

Thanks for any hints!

/p

Replies are listed 'Best First'.
Re: $@ gets set differently on eval and Log::Dispatch::Email
by Anonymous Monk on Aug 12, 2013 at 11:12 UTC

    Thanks for any hints!

    see Devel::EvalError it will probably help some (Why $@ is unreliable)

    or post code that reproduces the problem, otherwise you're waiting for someone to remember :)

    I like the die/exit( 0 ); combination :)

      see Devel::EvalError it will probably help some (Why $@ is unreliable)

      Thanks, that's the right direction, using Devel::EvalError instead of eval directly works. Does this package provide any hints on where eval and DESTROY are used without localizing $@? That's how I interpreted some of the statements but I can't figure out how to enable mentioned debug output. I came across that problem before in some of may packages and added a localization of $@ in DESTROY by convention. I think I would prefer this workaround for now until I maybe decide to switch to Devel::EvalError everywhere. I couldn't find any combination of DESTROY and eval in Log::Dispatch but there must be one somewhere as without Log::Dispatch everything was working fine...

        I couldn't find any combination of DESTROY and eval in Log::Dispatch but there must be one somewhere as without Log::Dispatch everything was working fine...

        For some reason the cause of the problem was not in Log:.Dispatch, but in one of my classes and their destructors. I didn't use eval directly, but indirectly it was used somewhere within Log4perl, which was used to log some debug statements in the destructor. After I added local $@; before the logging statements error trapping worked again. Don't know why the problem was only triggered using Log::Dispatch, though.

        Looks like I have to really switch to Devel::EvalError in the future, problems like this are very hard to find.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://1049105]
Approved by marto
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chanting in the Monastery: (5)
As of 2024-03-19 03:24 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found