We should make it a config variable that defaults to the old behaviour but
adjust -Devel to default it to true in new apps.
This keeps back compat, but makes new apps behave 'correctly'.
+1 from me.
t0m
Aristotle Pagaltzis wrote:
>* Bill Moseley [2013-05-10 17:15]:
>> What would the develop
* Bill Moseley [2013-05-10 17:15]:
> 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?
I’ll second that, I’d love to drop some more unbreak-me boilerplate.
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 t
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, wh
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.
