Description
Current catalyst adds exceptions to $c->error and generally trys to catch them in a global Root.end action. This is fine for simple applications but has two issues I have run into.
-
global end action gets very complex for any application of size. Often becomes a mess, a sort of "gods action."
-
The error is handled at a distance from where it was actually caused. There is no good way to 'restart or resume' from the point of error, and the actions that general the error have no good way to influence how the error is handled.
If would be nice if you could declare at the application level, and augment/modify at the context scope, classes of errors and handlers for them. For example if you hit a DBIC not found error, that could be setup to redirect to a not found or database error pages.
Would give you a way to approximate something like continuations, just not as good.
For chained actions you'd need to be able to pass a reference to th next action in the chain so you could recover from the error and proceed.
advantages would include the ability to declare upfront how to handle certain types of errors and actions can change or augment those. Would come closer to resembling lisp continuations, which I find to be the only sane exception system I've every used :)
Another nice benefit is we could build on the code we added to support HTTP Exceptions (this system would actually just be a generalization of that, and the custom code written for HTTP Exceptions would be removed and subsumed by this.
Here's an example, you have an action that takes an Arg and uses it to lookup a database row. However if the Arg causes an exception, instead of aborting the entire request and dumping a generic error page we replace the row with a new one, and continue processing. (I know that's a bit hand wavy...)