Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Handle application errors with mod_perl

by dvwright (Initiate)
on Feb 07, 2013 at 02:31 UTC ( [id://1017544]=perlquestion: print w/replies, xml ) Need Help??

dvwright has asked for the wisdom of the Perl Monks concerning the following question:

Howdy,

I have some legacy Perl CGI scripts running under mod_perl.

SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI

When a application level, Database related Software error occurs, raw SQL gets output to the browser. Basically the same message as found in the error_log. (e.g Software error: Can't execute 'SELECT,.. etc)

The access_log does show this as a HTTP 500 error, however setting ErrorDocument within httpd.conf does not catch it)

In the past I have used CGI::Carp qw(fatalsToBrowser) within a script to catch errors and display a custom message, however in this case there are enough scripts that it would be preferred if I could just define a handler or callback somewhere to capture the output and return the output of my choice. (like how Apache can set ErrorDocument)

I thought maybe I could get at through PerlLogHandler or maybe even subclassing RegistryCooker but it looks like that won't work.

Ideas? it seems like a simple thing I am overlooking.

Apache/2.2.3 mod_perl/2.0.5 CentOS release 5.5 (Final)

Thanks


UPDATE: Turns out I cant use fatalsToBrowser either, currently I'm looking into this: $SIG{__DIE__} Thanks



FINAL UPDATE with solution:

Yes, so the whole point is A. not leaking sensitive details to end users and B. 'save face' in front of customers.
So, the reason why the Apache setting ErrorDocument was not working was because there is also a reverse proxy running. To enable:

ProxyErrorOverride On

Another approach is to write your own PerlResponseHandler (see ModPerl::Registry, basically you subclass ModPerl::RegistryCooker.
my $old_status = $my_rc->{REQ}->status; my $rc = $my_rc->run; if ($rc == 500){ # 500 error occured

Replies are listed 'Best First'.
Re: Handle application errors with mod_perl
by jhourcle (Prior) on Feb 07, 2013 at 17:19 UTC
    It might be overkill, as it'll run for every request and not just those that generated errors, but I would think that an Output Filter should be able to catch the 500s and re-write them.
      Thanks, this looked very promising. Unfortunately it does not seem to get along with mod_proxy (a reverse proxy) which I am also running.
Re: Handle application errors with mod_perl
by sundialsvc4 (Abbot) on Feb 07, 2013 at 14:19 UTC

    What you should do, really with regards to any substantial Perl application but especially in the case of mod_perl, is to place a “catch-block of last resort” around the entire guts of the application.   If an error is raised that is not caught by anyone else, this catch-block (eval in Perl) will catch it and thus maintain control.   (The situation, now, is very questionable, such that perhaps the process after sending back its response should kill itself and be re-born.)

      (The situation, now, is very questionable, such that perhaps the process after sending back its response should kill itself and be re-born.)

      LOL

Re: Handle application errors with mod_perl
by sundialsvc4 (Abbot) on Feb 07, 2013 at 20:58 UTC

    Gentlebeings ... a moment’s respectful pause, I beseech thee ...

    The root cause of the problem, with respect to this mod_perl-based application, is not that a misfortunate error occurred ... but that the consequence of that error, when it misfortunately occurred, was that the exception blew all the way out to “Apache, itself.”   Any self-respecting web application, in whatever implementation-language it might be, must be able to keep up a good face in front of its audience while the show is going on, no matter what sort of calamity is happening backstage.

    “Ladies and Gentlemen, good evening.   I’m very sorry, but the entire back-half of the theater has just been consumed by an unanticipated thermonuclear fusion reaction.   Will you please now gather your coats and exit through the doorways to the left or to the right.   You may exchange your tickets for a full refund at the box-office tomorrow morning if the aforesaid box office is still here.   Thank you, and good night.”   Grace under pressure.

    “SQL errors,” (will surprises never cease??) ... guess what ... sh*t happens.   Just like any other sh*t that “could happen.”   But the bottom line is ... no matter what happens, you gotta save face in front of the customer.

    Ergo:   you must, above all else, ensure that there is “an exception-handler of last resort.”   And, having built that, you must likewise ensure that it does something reasonable.   Hand the doomed customer a free drink along with his life-jacket.   But don’t, whatever you do, actually let the airplane hit the ground.   That’s not “Perl” ... that’s not even “web.”   That’s just common sense.

    The second point, likewise, is “just common sense.”   If the theater that you are running has just experienced a thermonuclear meltdown, for reasons that you particularly know not, then it just might be prudent to commit suicide, so that the operating system will obliterate all the wreckage.   Apache, in its turn, will then spawn a brand new clean-slate.

    Hey ... if that “bothers you,” then with my blessings please down-vote this response to your heart’s content and have a wonderfully nice day.

      But the bottom line is ... no matter what happens, you gotta save face in front of the customer.

      On a complete tangent over to human relations, that is the cause of a lot of headaches I hate. When you know there is a problem, and they just won't admit it. It makes the denier look bad, and problems don't get solved.

      Don't save face. After all, Step One is admitting that there is a problem.

        Acknowledge a problem exists, but pull your pants up :) C.Y.A - Cover Your A.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://1017544]
Approved by ww
Front-paged by vinoth.ree
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others pondering the Monastery: (5)
As of 2024-03-19 09:29 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found