I've attached a tar.gz of all the files I added and/or changed. I'm not
sure of what format things are supposed to be in, so I just pulled all
the new/modded files together in one directory and tar/gz'ed them up.

Changed:
        lib/CGI/Application.pm
        MANIFEST
        Changes
New:
        t/10errormode.t
        test/TestApp11.pm
        test/TestApp12.pm

I've marked this version as 3.23 in Application.pm, if that's ok.

Thanks,
Rob

-----Original Message-----
From: Mark Stosberg [mailto:[EMAIL PROTECTED] 
Sent: Monday, August 23, 2004 7:15 PM
To: [EMAIL PROTECTED]
Subject: Re: Proposal for Error handling runmode

Rob --

On 2004-08-23, Kinyon, Rob <[EMAIL PROTECTED]> wrote:
> 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.

I'm warming up to this idea.  However, I think having both "error_mode"
and "error" is confusing and unnecessary.

I thought the syntax would be more like this for the user:

sub setup {
        my $self = shift;

        $self->error_mode('my_error_handling_rm');

}

'my_error_handling_rm' would be stored in $self->{__ERROR_RM}.

Then, this would be called only if it's defined. 

This removes the need to have 'sub error' defined, which 
provides no additional value, since it simply repeats the default
action of having no error_mode defined.

Would you be willing to create a patch for this feature (including code,
docs and tests) for a final review?

        Mark
 
--
 . . . . . . . . . . . . . . . . . . . . . . . . . . . 
   Mark Stosberg            Principal Developer  
   [EMAIL PROTECTED]     Summersault, LLC     
   765-939-9301 ext 202     database driven websites
 . . . . . http://www.summersault.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. 

Attachment: changes.tar.gz
Description: changes.tar.gz

---------------------------------------------------------------------
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