I would change that slightly. What I have is the following:

    my $body;

eval {
    if ($self->can($rmeth)) {
        $body = $autoload_mode ? $self->$rmeth($rm) : $self->$rmeth();
    }
    else {
        $body = eval { $autoload_mode ? $self->$rmeth($rm) :
$self->$rmeth() };
        die "Error executing run mode '$rm': $@" if $@;
    }
};
if ($@) {
    $rmeth = $self->error_mode;
    die $@ unless $self->can($rmeth);
    $body = $autoload_mode ? $self->$rmeth($rm) : $self->$rmeth();
}

If an error_mode isn't set, then you shouldn't call it. Or, rather, the
default error_mode should "die $@;". This way, you can tailor runtime
failures if you want, and redispatch up the chain if you don't want to
catch that runtime fatality. Maybe, something like:

1) error_mode() defaults to error()
2) CGI::Application::error() is defined as "sub error { die $@ }" ($@ is
propagated, so it can still be used.)
3) You will still need the can() call, just to make sure that the
redefinition didn't result in an uncallable method.

Just to be absolutely clear, this is not meant to capture errors like
bad input. This is meant to capture problems like HTML::Template dying
with bad params or a mistyped method call or recursion that goes too
deep.

Not everyone can use Apache's ErrorDocument.

Rob

-----Original Message-----
From: Michael Peters [mailto:[EMAIL PROTECTED] 
Sent: Saturday, August 21, 2004 7: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 
  
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]

Reply via email to