Best practice for angular service return value

Question

I have a number of angular services (e.g. a user service) which make various HTTP calls and I'm wondering what the best practice would be for handling errors. For example, I could do:

function getAll(success, error) {
 $http.get('/api/users').then(success, error);
}

Or I could do:

function getAll(success) {
 $http.get('/api/users').then(success, function(err) {
 success([]);
 });
}

The advantage of the former is it is more configurable in case I wanted to do something special. However, the advantage of the second is that it keeps the controllers simpler and in the (hopefully rare) case that the server is down it won't simply throw an error but will just display blank/empty data.

Is there any guideline or accepted best practice for this kind of situation?

• Ewan: what about using a promise?
• Ixrec: In many apps there's a meaningful difference between "you have no widgets" and "due to an error we could not get your widget list." Are you sure you won't ever want to make this distinction?
• Pace: A promise wouldn't be much different than taking in a success/failure callback. I'm trying to avoid propagating the failure handling logic all the way up the stack. In synchronous code this would be equivalent to having a try/catch at every layer in the hierarchy due to a potential error at the lowest layer which I would view as an anti-pattern. To make the distinction I could always log an error message to an error service which displays the message to some global error (non-view specific) field visible to the user.
• JC Ford: Your second example also returns a promise.
• Pace: Thanks, didn't mean to be returning anything in either call.

Answer 1

My preferred pattern is that the api layer returns a promise which is resolved if the call is successful (whether it found any data or not) and rejected only if the call failed.

A call to getCurrentUser for instance is supposed to either return a user or tell me that user doesn't exist or that I don't have adequate permissions or various other things. If it does any of those things it is supposed to do, the api call itself is successful and the result should be passed back to the caller. If instead, I get a 4xx or 5xx error code, then the call itself failed and the caller should be notified.

Let the api layer worry about making the call and returning the data. Let the data layer worry about interpreting the data and updating models. Let the UI layer about presenting the data and notifying the user if there was an error.

• Pace: Thanks, I realize now I could have formatted my question better. I suppose the question is more, "Should the API layer translate the 4xx/5xx into something else before sending it to the data layer? If so, what? Or should the API layer send the 4xx/5xx as is to the data layer for the data layer to interpret?" For example, if this were a synchronous server I would just throw an exception.
• JC Ford: That depends on the response code and whether you wish to be specific about the nature of an error when notifying the user. The user is almost certainly not going to understand the error or be able to do anything to fix it. So let them know about the failure, but be vague and don't communicate anything that can be used to compromise your system
• Mawg: Maybe you ought to rephrase the question?