Composition of error handler + interceptors should be more flexible

[mkotsur]

For ngResource there are 3 places to handle HTTP errors:

• Interceptor on global level defined via $httpProvider (further global interceptor),
• Interceptor defined for every action of every $resource (further local interceptor),
• Error handler specified within the call of the action (as a second error handler argument).

The demo of all 3 ways is here: http://plnkr.co/edit/wWGzbEUj1Gr2KwmxTrmx

There are 2 problems with this:

• The order is kind of illogical: global interceptor -> error handler -> local interceptor;
• There is no way to let know from the error handler that interceptors should not handle that error anymore.

Now the use-case: I want to make user aware of every failed request. But:

• Some of them I'll handle in my controllers where I call the action. Let's say show very nice error message, or implement the fall-back logic;
• Some of them are resource specific. Like if I have User resource and it returns me 404 not found, I always want to redirect somewhere;
• And finally all other errors. I want no silent failures to happen and I write a global interceptor which will handle all error responses (if they are not handled yet) and show growl-style notification with HTTP code and error message from server.

Currently it's only possible to talk from error handler to local interceptor by setting some response._handled = true (not really nice), but global interceptor is always executed first and thus completely out of control.

The solution could be:

1. Add a an order attribute to interceptors. Error handler can have some default value and interceptors get order assigned relative to that;
2. Some way of preventing interceptors of being called from the error handler.

[albv]

+1

[marceljuenemann]

+1
This would simplify error handling in angular apps alot!

[ghillert]

+1
Just found this issue. I am kind of surprised this issue has not been addressed yet. Have almost the same use-case as @mkotsur

[johnnncodes]

+1

I also have almost the same use-case as @mkotsur .

[caitp]

I've looked at the issue about how interceptors work in a different issue (re the "The order is kind of illogical: global interceptor -> error handler -> local interceptor;" problem), but I didn't submit a patch because I believe the current limitations were a conscious decision, and it would be a breaking change either way.

Still, could look at going with (or at least discussing) a different model for the interceptor pipeline

[adityasharat]

+1

[dvdplm]

having this issue as well. Anyone know of a possible workaround? :/

[dvdplm]

Ended up by adding a flag to the config map used to send off the request – handleOwnErrors – then checking for it in the interceptor: if set, do nothing and let the "local" code handle the error. Not pretty, but seems to work.

[gkalpak]

I think this is one of those cases were you can't make everyone happy. (Some people would want to one order, some the other and making every detail configurable will just make the API unleasant for everyone.)

Also note that there are two distinct interceptor pipelines at play here (the one for $http and the one for $resource) that should not be intermixed.

Considering that the current implementation was a conscious decision and that it is already possible to achive what you want (in a reasonable - if not ideal - way), I am going to close this.

That said, I admit that the current interceptors/tranformRequest/transformResponse story for $resource needs improvement. Let's move the discussion to #9334.