Stas Bekman <[EMAIL PROTECTED]> writes:
> 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]
>> 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?
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
