axios: Don't throw error / catch on 400-level responses

This has been added as a feature in 0.11.0 by use of validateStatus config option.

@carlojacobs you can access error.response.data

axios.post('/').then(response => {
    console.log(response.data);
}).catch(error => {
    console.log(error.response.data);
});

The problem is with response interceptor. It puts error object in then callback instead catch:

axios.interceptors.response.use(response => {
  return response;
}, error => {
  return error;
});

I can’t think of a compelling reason to have axios to take server errors and throw them as runtime errors. Much preferred to handle the response codes manually, especially since TypeScript doesn’t provide types for thrown errors that I’m aware of, so you end up having to go digging through an untyped object to try to figure out what the heck is going on. It also breaks up app flow considerably. Just one mans opinion.

@mbektimirov After seeing @clayreimann suggestion I have changed my interceptor as below. Now error resolves in catch block rather than then block.

Hope this helps someone.

axios.interceptors.response.use(function (response) {
  return response;
}, function (error) {
  return Promise.reject(error);
});

It’s hard to make a change like this at this point. Where people expect it to catch on anything outside of the 2xx range. In retrospect, if the request was made, and a response received I would have preferred it to be considered a success. This would be a much less opinionated implementation, and much better IMO. I think the way to handle this now would be to pass a config option that specifies what range to catch on, defaulting with anything outside of 2xx.

Same thing for me, 400 (BAD REQUEST) error resolves in then, not in catch. Very annoying bug, breaks all REST flow.

@mbektimirov A little late here, but I’m guessing that you’re seeing the error in then because your error callback isn’t throwing the error.

(on 0.16.2) - 400 Response still resolves in then instead of catch, and response object is undefined regardless of what server returns.

I totally y agree, it shouldn’t throw any error passed 500 errors, which basically prevents doing any REST… I think this is very “bad design” (don’t be mistaken, the library is great!!)

How is this resolved pass 0.11.0, any example on how to use the option maybe ? (using 0.16 here) Is there any way to use this in a classic GET/POST shortcut?

Thanks!

axios.defaults.validateStatus = function () {
    return true;
};

Or

axios({
    ...,
    validateStatus: function () {
        return true;
    }
});

+1 Using axios for the first time. Definitely like it, but did just run into this; it would be great for the 400s to not throw errors. Yay! Assigned and in progress as of 4 days ago. Thanks y’all!

The code says that it’s resolved when request.status >= 200 && request.status < 300 and rejected in any other case.

https://github.com/mzabriskie/axios/blob/1629a026da17a1e1d8999a02f3fe6b6b60aaac9c/lib/adapters/xhr.js#L58 https://github.com/mzabriskie/axios/blob/db85c7bf3ae19d680f5c16cd85d06c5e11fedc5f/lib/adapters/http.js#L80

I’m confused. Does axios fail the promise on 4xx? This thread makes it sound like it DOES, but in my code i’m getting a resovled promise on status 4xx. It doesn’t appear to be documented.