I have implemented a "die handler" for a group of modules that I have "integrated." Just like I wanted them to all use the same config file and object, I wanted them to "die" the same way.
This proved trickier than it sounds given mod_perl's special way of diing - using the Apache exit function. Anyway, I've attached the magical code that works for my app. Whenever a fatal error occurs (ie, die is called), the user sees a screen formatted like the rest of their application that reports the top level error. Some errors are too revealing, however, so I may curtail the message sent to the screen in the final release. The full carp of errors is logged. Note: This module relies on $dab to provide certain config options, etc. Replace its use with filenames to HTML::Template files containing the appropriate fields. I eventually want to incorporate some sort of exception handler into my scheme - I know Jesse has talked to this for C::A in the past on this list; basically, he was unable to choose one exception handler over another, IIRC. My collection of modules, now collectively known as 'DMart' will first be released in just a couple of weeks. Bill Catlan --- Mark Stosberg <[EMAIL PROTECTED]> wrote: > On 2004-08-23, Kinyon, Rob > <[EMAIL PROTECTED]> wrote: > > I initially tried to get Apache 2.0.50's > ErrorDocument to work, but I > > wasn't able to pass a parameter to it. > (ErrorDocument 500 > > /cgi-bin/main.cgi?mode=error didn't work, for some > reason ...) So, I > > wanted to trap Perl runtime errors. > > > > Your suggestion of an error run-mode is orthogonal > to my goal, as it > > doesn't solve the same problem. I would think that > both error-handling > > routines should be included in CGI::Application. > > > > I would think that the error_mode concept I > outlined should be included > > in the main C::A distribution because it will > allow CGI::Application to > > handle Perl runtime errors in situations where you > either cannot control > > the httpd.conf and/or you are working with a > webserver that doesn't > > provide this hook. If you don't want to use the > functionality, you don't > > have to. Just don't define an error_mode. Unlike > start_mode, a default > > would -not- be provided. (Or, rather, the default > would be to delegate > > handling of runtime errors to the caller of C::A.) > > Rob, > > Thanks for the response. Your counter-points are > sound. While I > understand your proposal would be backwards > compatible, I have concerns > that it could promote what I think is poor > application design-- sending > un-trapped perl death messages to the user. > > Granted, it would be possible to design an > error_mode that behaved > better: It could write the error to a log file, and > return a generic and > friendly error message to the browser. > > I'm interested in feedback from other C::A users on > the list: > Is this an interesting feature you would use? > > Mark > > -- > . . . . . . . . . . . . . . . . . . . . . . . . . . > . > Mark Stosberg Principal Developer > [EMAIL PROTECTED] Summersault, LLC > 765-939-9301 ext 202 database driven websites > . . . . . http://www.summersault.com/ . . . . . . . > . > > > --------------------------------------------------------------------- > Web Archive: > http://www.mail-archive.com/[EMAIL PROTECTED]/ > > http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > >
DieHandler.pm
Description: DieHandler.pm
--------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
