Jesse Erlbaum wrote:
Hi Steve --I've replaced the "hacked" version of 3.0 that I was using with 3.1 and the postrun method seems to work fine. Thank you!
Do you have a new ETA for 3.1? I'd really like to start getting to grips with the new post-run stuff.
Sorry for the delay!
In the mean time, everybody should let me know if they find any problems
with the implementation of cgiapp_postrun().
However, I do still have one remaining niggle. I mentioned on the list at the end of April that I'd like to see "use CGI::Carp;" replaced with simply "use Carp;". There were several murmurs of agreement at the time, but this change is not in 3.1. Was that intentional, or an oversight?
The reason that I don't want CGI::Carp loaded is that it either installs a $SIG{__DIE__} handler (which is a highly dubious means of working, strongly discouraged at such a global level by most Perl gurus -- see threads about it on p5p, or read the mod_perl docs), or a CORE::GLOBAL::die override (a better way to do things, but still annoying when you don't want it). Worse still, it has changed from one method to the other in fairly recent times, and more recently still there have been conversations on the mod_perl mailing list about possibly changing back because CORE::GLOBAL::die overrides don't catch compile-time errors. This makes it a moving target to try to work around for those of us that don't want such a module doing anything with exceptions for us.
Personally, I use the excellent Exception::Class module to handle all my exceptions, so I'd really rather not have to contend with whatever CGI::Carp might be doing in the latest version.
As I said before, C::A sub-class authors can always add "use CGI::Carp" to their application super-classes if they do want CGI::Carp involved.
Regards,
Steve
--------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
