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 -----Original Message----- From: Mark Stosberg [mailto:[EMAIL PROTECTED] Sent: Saturday, August 21, 2004 10:27 AM To: [EMAIL PROTECTED] Subject: Re: Proposal for Error handling runmode On 2004-08-19, Kinyon, Rob <[EMAIL PROTECTED]> wrote: > > What do folks think about allowing an error-handling runmode within > CGI::Application. Do something like: > > sub setup > { > my $self = shift; > > .... > $self->error_mode( 'error_in_page' ); > .... > > $self->SUPER::setup( @_ ); > } > > Then, within C::A::run(), eval around the call to $rmeth and, if $@ is > set, set $body equal to the result of a call to $self->error_mode. If > that sets $@, then continue as it happens today. I think this is a useful suggestion. In my own sub-class of CGI::Application, I have an error handling run mode that I use to send messages to browser. Since I don't believe in showing technical gibberish to website visitors, usually my messages have titles like "Technical Failure", or "Insufficient Information", with short descriptions of what's wrong. [ Thanks about implications. ] This solution is a little less flexible, because the only input you give to "error_mode" is "$@". You would then have to parse the string to see whether you got back a friendly error message (from an intentional "die"), or some deadly error from deeper in Perl. In that case, it serves as little more than a customized "internal server error" page. I think I like my solution better, which works more like this: 1. Create an customized internal server error page as a catchall. Implement with Apache ErrorDocument directive. ( I usually skip this entire step. ) 2. Use my own error() routine for simple error messages to return the user. Most commonly these are: - "Insufficient Information", i.e: propeller_id was missing - "Technical Failure": I eval'ed some chunk of code and it died unexpectedly. A call to my error routine might look like this: my $q = $self->query; my $id = $q->param('id'); # check that ID is present and a digit or throw an error ($id =~ m/^\d+$/) or return $self->error( title => 'Insufficient Information', msg => 'Insufficient information was recieved to process your request.' ); The actual error() routine is as simple: sub error { my $self = shift; my %args = @_; my $tmpl = $self->load_tmpl('error.html'); $tmpl->param(%args); return $tmpl->output; } ########## It's so simple that I have to wonder whether it's even worth adding to CGI::App, even as a plug-in. Mark -- http://mark.stosberg.com/ CONFIDENTIALITY NOTICE: The information in this electronic transmission and any documents accompanying it may contain confidential information belonging to the sender, which is legally privileged. The information is intended only for the use of the individual or entities named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this transmission in error, please destroy the message in its entirety. --------------------------------------------------------------------- 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]
