Joe Schaefer wrote:
No good, IMO. How users trap errors is for them to decide, not us. Their eval blocks might be wrapping a large section of third-party code, and not all of the trapped exceptions will come from mod_perl.
that's why they first need to check
if (ref $@ eq 'APR::Error') { check rc code here }
but what do I know, all I see is the tests...
Yup, but the exception handling code may have been written
years before apr ever existed. So we really shouldn't be
generating spurious exceptions based on how some crufty old code treats [EMAIL PROTECTED]
Agreed.
If it were my decision, I'd set fallback => 1 and optimize that by providing subs for the common operations, like '=='.
sounds good to me. Go for it then, Joe.
Will do. While I'm at it, I'd also like to redo strerror to become a class method, so we'd implement APR::Error::str() this way instead:
sub str { my $class = ref $_[0]; return sprintf "%s: (%d) %s at %s line %d", $_[0]->{func}, $_[0]->{rc}, $class->strerror($_[0]->{rc}), $_[0]->{file}, $_[0]->{line}; }
That way apps like apreq can subclass APR::Error and just provide a strerror() method without needing str() also, and the "$@" stringization remains uniform.
Thoughts?
+1 (don't forget to update the docs :0)
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
