Ross Thomas wrote:
>
> I'm relatively new to Apache::ASP and have been trying to install a __DIE__
> handler to catch exceptions thrown deep within code. My aim is to be able to
> call die() from anywhere and have it caught in a central location where I
> can parse the message and display the appropriate HTML to the user. I
> especially want this to work with DBI and RaiseError => 1.
> ...
> As you can see, my custom handler was apparently never called. The same
> thing happens if I define an actual subroutine and assign a reference to it
> instead of using an anonymous sub.
>
> When I move the $SIG{__DIE__} = sub { ... }; assignment into Script_OnStart,
> it *does* get called, but I get this output:
>
> ----------------------------------------------------------
> something tragic happened
>
> Errors Output
>
> Can't find label APACHE_ASP_EXECUTE_END at /usr/share/perl5/Apache/ASP.pm
> line 3627. , /usr/share/perl5/Apache/ASP.pm line 1556
>
I tried to get around this problem just now, but could not.
$Response->End() uses a goto internally to jump to the end of
the request cycle just before Script_OnEnd ( in 2.33 at least ).
A die() seems to loose track of goto symbols like APACHE_ASP_EXECUTE_END
even in a $SIG{__DIE__} so you cannot $Response->End() in a die()
handler.
I do not know what to recommend. You could try overriding die() locally
itself, but I do not think you will get much mileage with that technique.
Genearlly, you just have a ErrorDocument that covers 500 internal
server errors, and tell the end user something generic. These
kinds of die() errors are fatal system errors so perhaps the
end user should not see them anyway, else you could just trap
the error in an eval{} and look at $@ normally.
If you want to consistently render an error for things you know
you can catch, you can try an eval in each of your scripts:
eval { ... some code ... };
if($@) { pretty_format($@) };
sub pretty_format { ...; $Response->End; }
One problem you would find is that if you do trap $SIG{__DIE__}
and use 3rd party modules that are catching their own errors
in eval, you may screw up their behavior when looking at $@
to decide what to do next, so I would not recommend overriding
$SIG{__DIE__} like this anyway. Such a module might protect
its die() by doing a local $SIG{__DIE__} = sub { die(@_ }, so
maybe this is less of a concern.
--Josh
_________________________________________________________________
Joshua Chamas Chamas Enterprises Inc.
NodeWorks Founder Huntington Beach, CA USA
http://www.nodeworks.com 1-714-625-4051
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
