I think it would be a good idea to have this as part of C::A, mostly due to the reasons tha Cees sited; that it is very simple to understand and use once it has been written, but it is not necessaraly obvious before it is written.
I do find it interesting that most programmers that use C::A have seperately written this type functionality but that the code hasn't made its way to the wiki or to CPAN. Cheers --Fred -----Original Message----- From: Michael Peters [mailto:[EMAIL PROTECTED] Sent: Saturday, August 21, 2004 4:10 PM To: [EMAIL PROTECTED] Subject: Re: [cgiapp] Re: Proposal for Error handling runmode Mark Stosberg wrote: > 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. > Or maybe have a built in error() sub that would be overridden in the application. This way, existing C::A wouldn't have to change and newer apps could benefit from it. > 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. If we do it as an overridden method then it can take any arguments that you want to recieve. Also, as a built in method it could be used as Rob suggested earlier to catch any errors from the eval of the run mode. This would still keep the flexibility that you use now and would also give the ease of doing something like ... die 'HERE'; inside of a run mode (while debugging, etc) and still being able to handle that error as you see fit (showing it inside of the browser, etc). Maybe it's just me, but I ran into some issues when trying to run a C::A as a mod_perl handler and getting CGI::Carp to show fatalsToBrowser since CGI::Carp does different stuff under mod_perl with evals. If something like the above had existed in C::A it would have made things much simpler. Now I'm just tailing the error logs. > It's so simple that I have to wonder whether it's even worth adding to > CGI::App, even as a plug-in. It is simple and a couple of lines to C::A code would add this functionality without changing stuff for you or anyone else. --- /usr/lib/perl5/site_perl/5.8.3/CGI/Application.pm 2004-08-17 12:19:28.000000000 -0400 +++ Application.pm.modified 2004-08-21 19:09:18.419310432 -0400 @@ -142,7 +142,7 @@ } else { $body = eval { $autoload_mode ? $self->$rmeth($rm) : $self->$rmeth() }; - die "Error executing run mode '$rm': $@" if $@; + $body = $self->cgiapp_error($@, $rm) if $@; } # Make sure that $body is not undefined (supress 'uninitialized value' warnings) @@ -179,6 +179,12 @@ #### OVERRIDE METHODS #### ############################ +sub cgiapp_error { + my ($self, $error, $rm) = @_; + die "Error executing run mode '$rm': $error" if $error; +} + + sub cgiapp_get_query { my $self = shift; How does everyone feel about this? -- Michael Peters Developer Plus Three, LP --------------------------------------------------------------------- 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] --------------------------------------------------------------------- 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]