> >>> You could use "eval" and "die", Perl's standard exception mechanism.
> >>
> >> I thought of that, but I was concerned that my module would suffer
> >> a performance hit. Granted, it's not a strong eval, but it just
> >> seems ugly. If that's the only way, I guess I'm stuck, but it seems
>
> Er, that "strong" should be "string" BTW...my bad :)
>
> >> to me that there should be some call like Apache->return(OK) or
> >> $r->return(OK) that I can call from any depth within a PerlHander
> >> that would behave as if handler() returned that value.
> >
> > In order for mod_perl to never return to your code from that $r->return()
> > it would need to pop the stack, since it needs to continue execution at
> > the point following its call to your handler(). This means mod_perl
> > is executing the handler in an eval block, so now it has to take over
> > all exception handling. Better to do your own, you have fine control
> > on what and where you use it.
>
> Yeah, I keep forgetting that Apache.pm is just a perl module itself and
> not some opaque magical entity ;) I guess I'll give eval a try. Thanks
> a bunch.
Well mod_perl source code is definitely opaque at times :-)
Magical only means some other piece of code is doing the work behind the
scenes.
Actually Apache.pm doesn't deal with this, it's a Perl interface to the Apache
C API, so when your Perl handler does something like $r->foo it finds its way
to the Apache ap_foo. The job of calling handlers is handled by the C handlers
registered by mod_perl. It's quite the opposite: mod_perl C code calling your
Perl handler.
--
Eric
