Re: [Catalyst] Chained and exceptions

[Lukas Thiemeier]

On 05/09/2013 03:25 PM, Bill Moseley wrote:
> I have a feeling I asked this before, but cannot find the post.
> 
> [info] Exception powered by Catalyst 5.90030
> 
> What's the reasoning that chained actions continue to run after an
> earlier exception?
> 
> 
> sub start : Chained( '/' ) : CaptureArgs(0) {
> warn "in start\n";
> }
> 
> sub middle : Chained( 'start' ) : CaptureArgs(0) {
> warn "in middle\n";
> die "died in middle\n";  # or e.g. throw access violation
> }
> 
> sub lastpart : Chained( 'middle' ) : Args(0) {
> my ( $self, $c ) = @_;
> $c->res->body( "finished\n" );
> warn "in lastpart\n";
> }
> 
> $ script/exception_test.pl  /start/middle/lastpart
> in start
> in middle
> *in lastpart*
> [error] Caught exception in Exception::Controller::Root->middle "died in
> middle"
> 

Hi Bill,

This is because you don't want Catalyst to die. Imagine you are running
a fastcgi server and you accidentally created an action which dies on
certain user input.
If Catalyst would die, the fastcgi server would die and your whole
application would not be available anymore. Instead, you want to report
the incident and keep the fastcgi server (Catalyst) running.

Because of this, every action is wrapped in an "eval{...}". Potential
errors are logged, but the server keeps running.

See "execute" in Catalyst.pm for implementation details.


To solve your problem, you can wrap your unsafe code in an eval or use
Try::Tiny (or whatever you prefer) and detach if the unsafe code dies.

Your Example would look like this:

use Try::Tiny;

sub start : Chained( '/' ) : CaptureArgs(0) {
warn "in start\n";
}

sub middle : Chained( 'start' ) : CaptureArgs(0) {
my ($self, $c) = @_;
warn "in middle\n";
try{
die "died in middle\n";  # or e.g. throw access violation
}
catch{ $c->detach };
}

sub lastpart : Chained( 'middle' ) : Args(0) {
my ( $self, $c ) = @_;
$c->res->body( "finished\n" );
warn "in lastpart\n";
}

If you do it like this, actions chained to the unsafe action will not
get executed if the unsafe action dies. In your case, "lastpart" will
never be executed, because "middle" always dies.

Lukas

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Chained and exceptions

[Bill Moseley]

On Thu, May 9, 2013 at 7:25 AM, Lukas Thiemeier
wrote:

> On 05/09/2013 03:25 PM, Bill Moseley wrote:
> > I have a feeling I asked this before, but cannot find the post.
> >
> > [info] Exception powered by Catalyst 5.90030
> >
> > What's the reasoning that chained actions continue to run after an
> > earlier exception?
> >
> >
> > sub start : Chained( '/' ) : CaptureArgs(0) {
> > warn "in start\n";
> > }
> >
> > sub middle : Chained( 'start' ) : CaptureArgs(0) {
> > warn "in middle\n";
> > die "died in middle\n";  # or e.g. throw access violation
> > }
> >
> > sub lastpart : Chained( 'middle' ) : Args(0) {
> > my ( $self, $c ) = @_;
> > $c->res->body( "finished\n" );
> > warn "in lastpart\n";
> > }
> >
> > $ script/exception_test.pl 
> /start/middle/lastpart
> > in start
> > in middle
> > *in lastpart*
> > [error] Caught exception in Exception::Controller::Root->middle "died in
> > middle"
> >
>
> Hi Bill,
>
> This is because you don't want Catalyst to die. Imagine you are running
> a fastcgi server and you accidentally created an action which dies on
> certain user input.
>

Hi Lukas,

Sorry, you missed the point.  Yes, Catalyst traps exceptions.  That is
expected and is done in handle_request when calling $c->dispatch.

I'm talking about breaking a chain of actions. Why would a later part
of the chain run if an earlier part threw an exception.   For example, what
if an earlier part of a chain threw a access violation.  In that case you
would not want the later chain to run.





> If Catalyst would die, the fastcgi server would die and your whole
> application would not be available anymore. Instead, you want to report
> the incident and keep the fastcgi server (Catalyst) running.
>
> Because of this, every action is wrapped in an "eval{...}". Potential
> errors are logged, but the server keeps running.
>
> See "execute" in Catalyst.pm for implementation details.
>
>
> To solve your problem, you can wrap your unsafe code in an eval or use
> Try::Tiny (or whatever you prefer) and detach if the unsafe code dies.
>
> Your Example would look like this:
>
> use Try::Tiny;
>
> sub start : Chained( '/' ) : CaptureArgs(0) {
> warn "in start\n";
> }
>
> sub middle : Chained( 'start' ) : CaptureArgs(0) {
> my ($self, $c) = @_;
> warn "in middle\n";
> try{
> die "died in middle\n";  # or e.g. throw access violation
> }
> catch{ $c->detach };
> }
>

Don't forget your semicolon. :)



>
> sub lastpart : Chained( 'middle' ) : Args(0) {
> my ( $self, $c ) = @_;
> $c->res->body( "finished\n" );
> warn "in lastpart\n";
> }
>
> If you do it like this, actions chained to the unsafe action will not
> get executed if the unsafe action dies. In your case, "lastpart" will
> never be executed, because "middle" always dies.
>
> Lukas
>
> ___
> List: Catalyst@lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/
>



-- 
Bill Moseley
mose...@hank.org
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Chained and exceptions

[Bill Moseley]

On Thu, May 9, 2013 at 8:31 AM, Bill Moseley  wrote:

> Hi Bill,
>
>>
>> This is because you don't want Catalyst to die. Imagine you are running
>> a fastcgi server and you accidentally created an action which dies on
>> certain user input.
>>
>
> Hi Lukas,
>
> Sorry, you missed the point.  Yes, Catalyst traps exceptions.  That is
> expected and is done in handle_request when calling $c->dispatch.
>

No, sorry, I responded too quickly.   I'm not talking about the entire have
exiting, of course.   I'm just not sure it makes sense to not check
$c->errors after calling each action in a chain.  What's the use case for
that?


-- 
Bill Moseley
mose...@hank.org
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Chained and exceptions

[Lukas Thiemeier]

On 05/09/2013 05:31 PM, Bill Moseley wrote:

> 
> 
> Hi Lukas, 
> 
> Sorry, you missed the point.  Yes, Catalyst traps exceptions.  That is
> expected and is done in handle_request when calling $c->dispatch.
> 
> I'm talking about breaking a chain of actions. Why would a later
> part of the chain run if an earlier part threw an exception.   For
> example, what if an earlier part of a chain threw a access violation.
>  In that case you would not want the later chain to run.
> 
> 

Well, I answered your first question:

> What's the reasoning that chained actions continue to run after an
> earlier exception?

Answer: Because Catalyst traps those exceptions. :)

Ok, now seriously:

I personally don't think that the current behavior is wrong. IMO a
chained action depends on its predecessor to be run, but not to be run
successfully. Maybe somebody wants to handle certain exceptions later in
the same action chain. I don't say that this is a good idea. I just say
that I can think of usecases where this would be useful.

As we both know, catching exceptions and detaching is easy. Not
detaching if detaching the default behavior would be more work.

But thats just my opinion.

I have found several old discussions about this topic in the archives. I
didn't go through all of them in detail. But I have  learned that the
main reason why this was never fixed is that it would break old
applications which rely on the current behavior.

Take a look here:
http://www.gossamer-threads.com/lists/catalyst/users/28788#28788

Lukas

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Chained and exceptions

[Tomas Doran]

On 9 May 2013, at 14:25, Bill Moseley  wrote:

> I have a feeling I asked this before, but cannot find the post.
> 
> [info] Exception powered by Catalyst 5.90030
> 
> What's the reasoning that chained actions continue to run after an earlier 
> exception?
> 


You're after this: https://metacpan.org/module/Catalyst::ActionRole::DetachOnDie

which gives you the alternate behaviour (i.e. detaching from the chain on first 
exception).

Cheers
t0m


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Chained and exceptions

[Bill Moseley]

On Fri, May 10, 2013 at 1:29 AM, Tomas Doran  wrote:

>
>
> You're after this:
> https://metacpan.org/module/Catalyst::ActionRole::DetachOnDie
>
> which gives you the alternate behaviour (i.e. detaching from the chain on
> first exception).
>

We have a number of applications, a few quite large, where some controllers
inherit from different base classes.   We could try and retro fit all
existing code, but it would be a good-sized project.  So the monkey patch
we did (as well as Dami Laurent had done in
2008)
is better for us.

I'm pretty sure this issue is not well known amongst our current (and
future) developers and thus it's quite likely someone would forget this in
a new Controller.

We all understand that an uncaught exception should not bring down the
server and instead generate a 500, but I think few would assume that when
using Chained an exception would not stop the request dead in its tracks
and instead is implicitly trapped and allowed to continue.

I think the more likely situation now is code running when it is not
expected -- which could be a serious security issue if the earlier action
in a chain is used for access control.

What would the developers think of deprecating this behavior (for the few
that might actually be relying on this) and issue a warning if a config
option is not set that fixes the issue?



-- 
Bill Moseley
mose...@hank.org
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Chained and exceptions

[Peter Karman]

On 5/10/13 10:10 AM, Bill Moseley wrote:


What would the developers think of deprecating this behavior (for the
few that might actually be relying on this) and issue a warning if a
config option is not set that fixes the issue?




+1

I have lots of ugly code that checks for $c->error in order to break 
chains. Not having to do that, or making it configurable, would be nice.


--
Peter Karman  .  http://peknet.com/  .  pe...@peknet.com

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/