Re: [cgiapp] Re: CGI::App 3.2 proposed release available

[Steve Hay <suppressed>]

Thilo Planz wrote:

>>Solution 1.
>>We could simply remove the catch/rethrow altogether, and leave it up to
>>Perl to say that the method can't be dispatched if that's the case:
>>
>>
>>Solution 2.
>>Slightly nicer than that:  Pick off those cases where the run mode
>>method dispatch might fail and use the catch/rethrow to give a nice
>>error in those cases.  Don't use it otherwise.
>>
>>Solution 3.
>>
>>Retain the exception catching in all circumstances, but provide (yet
>>another) overridable method, cgiapp_exception(), to deal with the
>>exception that we've just caught.  The default implementation of the 
>>new
>>method would, of course, be the current behaviour.
>>    
>>
>
>
>  
>
>>Which solution do you prefer?  What other solutions are there?
>>    
>>
>
>I like solution 1 over solution 2.
>
>Solution 2 has the same problems as the current implementation in that 
>it treats exceptions returned from auto-loaded methods as strings.
>I never thought of auto-loading in the first place, but if we are to 
>support it, we should do it properly (including allowing it to die with 
>exceptions).
>
I prefer solution 2 because I feel sure that it is The Right Thing to do 
in the case of non-autoloaded run mode methods (i.e. just run the method 
without any catch/rethrow shenanigans), which is almost invariably what 
people will be using.

For the (probably quite rare) case of auto-loaded run mode methods 
solution 2 just maintains the status quo: a conservative point of view 
that, as Mark indicated, allows us to introduce further complexity later 
if/when somebody really does need it fixing.  We also don't commit 
ourselves to any new API hooks at this stage either.

>
>I see your problem with solution 3, in that cgiapp_exception adds an 
>additional stack frame if it dies.
>However, cgiapp_exception does not necessarily have to die at all.
>It could just produce a nice error page, and then return to let run() 
>finish its work (headers, teardown and all)
>What I am currently doing is an extended version of solution 3.
>
That's a possibility, but my exception handling is "higher up" than the 
CGI-App level: it's all within a mod_perl handler that runs the C::A 
app, and which already has methods to handle exceptions appropriately, 
including outputting nice error pages.  I really want my C::A to just 
return to that higher level, rather than having its own error handling 
itself as well.

Thus, solution 3 (even as modified in your solution(s) 4 below) only 
really provides users with the ability to handle exceptions better 
within their C::A subclass.  It doesn't help those that want to handle 
exceptions outside of the C::A hierarchy without interference from C::A.

- Steve

>
>Solution 4
>
>cgiapp_exception is allowed to return a result, which is then sent to 
>the client (instead of the normal runmode output).
>
>  
>
>>    # Process run mode!
>>     my $body = eval { $autoload_mode ? $self->$rmeth($rm) :
>>$self->$rmeth() };
>>-    die "Error executing run mode '$rm': $@" if $@;
>>+    if ($@) {
>>+        $body = $self->cgiapp_exception($rm, $@); # in case 
>>cgiapp_exception does not die
>>+    }
>>    
>>
>
>
>We could solve the stack frame thing by not having cgiapp_exception 
>defined in the base class,
>and only calling it "if we can()"  (because it has been defined in 
>subclasses).
>If it is not defined, we just die as in solution 1
>
>      # Process run mode!
>      my $body = eval { $autoload_mode ? $self->$rmeth($rm) :
>$self->$rmeth() };
>-    die "Error executing run mode '$rm': $@" if $@;
>+    if ($@) {
>+	if ($self->can('cgiapp_exception'){
>+        	$body = $self->cgiapp_exception($rm, $@);
>+	}
>+	else{
>+		die $@;
>+	}
>+    }
>
>
>
>Thilo
>  
>




------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only.  If you have received this message in error or there are any problems, please notify the sender immediately.  The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden.  Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd.  The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed