Error 'Response for getList SHOULD be an array and not an object or something else' does not reject promise

I am developing the front-end of a client’s application, with no control over the backend beyond my ability to harass their developers.

At present, they have a bug in which under certain circumstances a request that usually returns a list [] is returning an object {}. This is bad and will be fixed, but we would like to catch the error and display a friendly message in the meantime.

Restangular causes an exception to reach the console, but, unfortunately, the promise for the .getList is never rejected:

promise = Restangular.all('endpoint')
    .one('node', $state.params.nodeId)
    .getList()
    .then (channels) ->
       # ...
       $scope.loadingStatus = 'success'
    , (error) ->
       $scope.loadingStatus = 'error'
       $scope.loadError = error

results in

Error: Response for getList SHOULD be an array and not an object or something else

but no rejection and hence no corresponding update to the $scope error properties.

I believe Restangular should be rejecting the promise here. This is not like an assertion error which is useful to show you that you have made a coding error; in this case the error is not under our control and we want our users to get a nice error message.

[mbertolacci]

I get the idea and the work around. I’m not suggesting that you remove the error entirely, just make it reject the promise. You could also use console.warn to get the message across.

My beef is that a non-compliant server should not be able to force a client side library to literally break the entire page in production. That’s just bad defensive programming.

Adding interceptors for everything gets you around this issue, but it’s laborious, and requires the programmer to guess in advance which APIs might break. We just got lucky that our counterparts writing the API made this error while one us us had a console open.

I totally accept the argument for enforcing the method signature to help programmers. If Restangular just rejected the promise, and logged to console saying ‘oh no, the server broke the rules!’, every developer using the library would be defended against this edge case, and the method signature would still be enforced.

Michael On 22/02/2015 12:55 AM, “Mike Grabowski” [e-mail] wrote:

As getList signature suggest, it expects to receive an array from the endpoint you are using. As you are choosing the methods to use while creating an application - those are typically implementation errors as you configured Restangular wrongly with your application. It’s worth noticing that this will raise an exception only if response from the API is successful. Otherwise - promise will be rejected with a runtime error defined by HTTP specification (like 500 Internal Server Error, 422 Unprocessable Entity and so on).

This error is there to let you know that you have set up chain of Restangular wrongly. In case your endpoint returns an object (single entity), refer to one() and get().

In case it returns something different, that’s embedded within metadata, like below:

{ status: “OK”, data: [Array], totalCount: 20 }

refer to response interceptors that are described in the docs.

If the production endpoint is likely to be changed multiple times without any kind of proper versioning, apart from being irritated that those devs have no idea how REST spec looks like, you can do additional checks in your response interceptor like so:

if (_.isArray(response)) { return response; } else { // do something weird here }

As you can see https://github.com/mgonto/restangular#addresponseinterceptor - in the description, the last argument is deferred that you can MANUALLY reject if you feel that’s the most appropriate way when response !== array. In that case, successful response manipulation will be omitted and error will not be thrown.

— Reply to this email directly or view it on GitHub https://github.com/mgonto/restangular/issues/962#issuecomment-75372637.

[grabbou]

@mbertolacci - kinda like open source discussions when to introduce a new feature! @mgonto?

I think that those two quotes are the perfect solution 😃

Adding interceptors for everything gets you around this issue, but it’s laborious, and requires the programmer to guess in advance which APIs might break

and…

Then the combined odds are roughly that it happens 1 out of every 7500 days. This means the library does not handle a 1/10000 edge case

I think that as long as this is very rare case to happen - it’s worth leaving an extra option for our users to handle that case, as in 10000-1 cases they might expect an error to be thrown 😃

I can’t say that adding response interceptors is complicated - it’s pretty clear in our docs and exposes deferred which can be easily rejected and I believe it is in many different cases by our users, e.g. to provide better error messages in some cases.