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]

Reply via email to