On Fri, May 10, 2013 at 1:29 AM, Tomas Doran <bobtf...@bobtfish.net> 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<http://lists.scsys.co.uk/pipermail/catalyst/2008-March/017789.html>) 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/
