Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error Callbacks #130

Open
jjn1056 opened this issue Jan 2, 2016 · 1 comment
Open

Error Callbacks #130

jjn1056 opened this issue Jan 2, 2016 · 1 comment

Comments

@jjn1056
Copy link
Member

jjn1056 commented Jan 2, 2016

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.

  1. global end action gets very complex for any application of size. Often becomes a mess, a sort of "gods action."

  2. 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...)

@jjn1056
Copy link
Member Author

jjn1056 commented Jan 3, 2016

App->on_condition(
Database => sub {
my ($controller, $c, @Args) = @_;
return 1; # error handled, continue to next action
return 0; # error not completely handled, continue to next condition handler, or dump to $c->error
}
);

sub action :Local {
my ($self, $c) =@_
$c->on_condition("Database")->push( sub { ... }); # layer a new condition handler at the action level
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant