Stas Bekman wrote:
So, next I'm trying to use exception objects with overloaded methods. Here is a demo, this time in perl:
package Err;
use overload 'bool' => \&num, '==' => \&num, '0+' => \&num, '""' => \&str;
sub str { my $self = shift; $self->{str};} sub num { my $self = shift; $self->{num};}
sub new { my ($class, $num, $str) = @_; bless { num => $num, str => $str, }, __PACKAGE__;
}
This is beginning to look a lot like the Exception::Class module. I use that module myself for exception handling, and it seems pretty good. It has a couple of operator overloads in it, but not all that you have above. However, using E::C involves subclassing it: typically, one has many subclasses, all derived from a single class which is itself derived from E::C::Base, so you could either add the extra overloads to some E::C::ModPerl class, or even suggest them as patches to E::C itself.
Just trying to save a bit of wheel re-invention ;)
Thanks Steve,
There is not much reinvention going on here, all the above code is all that we need. Our model is much simpler and E::C seems like an overkill to me at the moment. The idea of (now) APR::Error is to be transparent to the user +$@ gives the $rc (that's why we overload == and 0+ ops) and "$@" gives you the stringified error, same as $! works. You don't need to be aware of the fact that $@ is now an object (besides doing the checking of ref $@).
If in the future we decide that we need E::C functionality, nothing stops us from moving to it, keep the code working as before.
-- __________________________________________________________________ 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]
