Quoting Mike Schilli ([EMAIL PROTECTED]):
Yeah, that's an old issue that dates back to Log4perl 0.42: There we
figured out that if someone wrote
$SIG{__DIE__} = sub { print die handler!\n; };
and used Log4perl and some module like Time::HiRes is missing, which
is acceptable, the handler gets triggered because eval { require }
causes an exception. Confusion ensued.
Ok, so you have a good reason for attempting this, which is great to
know. I was really wondering why you would do this.
Now, I've always thought that this is a bug in perl, nobody writes die
die handlers 'correctly'. To comply with users who get confused with this
confusing behaviour, I put this module_available() hack in place, which,
admittedly, sucks.
;-)
What to do? Going back to eval { require } would break every user with
sloppy die handlers.
No, if you read the patch on rt closely, you will see it puts a 'local'
die handler in place, just for the scope of the eval. This will
temporarily override all other die handlers, safely do an eval and then
return the result and unmask the users die handlers afterwards. This is
entirely safe to do and the eval will not trigger the users die handlers
anymore. You can just apply the patch as is and you will not break users
code.
Regards,
--
Merijn Broeren | We take risks, we know we take them. Therefore, when things
| come out against us, we have no cause for complaint.
| - Scott, last journal entry, march 1912
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
log4perl-devel mailing list
log4perl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/log4perl-devel
