Tengo exactamente el mismo entorno. Prueba esto:

axios.post('/formulas/create', {
    name: "",
    parts: ""
})
.then(response => { 
    console.log(response)
})
.catch(error => {
    console.log(error.response)
});

Modifique de console.log(error) a console.log(error.response) en catch .

También puede usar un interceptor global y rechazar solo error.response . El problema es que cuando console.log intenta mostrar el error, se imprime la representación de la cadena, no la estructura del objeto, por lo que no ve la propiedad .response .

En caso de que alguien se pregunte cómo rechazar solo la propiedad response , aquí se explica cómo hacerlo:

axios.interceptors.response.use((response) => {
    return response;
}, function (error) {
    // Do something with response error
    if (error.response.status === 401) {
        console.log('unauthorized, logging out ...');
        auth.logout();
        router.replace('/auth/login');
    }
    return Promise.reject(error.response);
});

La parte importante es return Promise.reject(error.response);

Esto produce el mismo resultado en caso de que la solución anterior estropee la sintaxis de su archivo JS al sangrar o minificar :)

.post('ajax/register/otp', this.registerData)
.then(function (response) {
       return otpSent(response)
})
.catch(function (error) {
      console.log(error.response);
 });

@ gopal-g no está definido para mí.

Bueno, @ pedro-mass, en ese caso, es posible que no haya respuesta del lado del servidor. en mi escenario, mi respuesta fue JSON cuando ocurrió un error, pude obtener la respuesta usando error.response

@ gopal-g Si estoy viendo la pestaña Red en las herramientas de desarrollo, puedo ver la respuesta. Es un 401 si eso marca la diferencia.

Tengo el mismo error con @ pedro-mass.

aquí está mi código

async function test () {
try {
  let res = await axios.get('/xxxxx/xxxx')

} catch (e) {
  console.log(e.response) // undefined
}
}

el uso de "error.response" no funciona, para mí. El problema ocurre cuando desconecté el servidor de la base de datos y mi servidor web devolvió el error 500.

Pestaña de red en herramientas de desarrollo

código de respuesta: 500
cuerpo de respuesta:

{
  "error": {
    "statusCode": 500,
    "name": "Error",
    "message": "read ETIMEDOUT",
    "code": "ETIMEDOUT",
    "errno": "ETIMEDOUT",
    "syscall": "read",
    "stack": "Error: read ETIMEDOUT\n    at exports._errnoException (util.js:1050:11)\n    at TCP.onread (net.js:582:26)"
  }
}

error de la consola de Chrome:

Uncaught (in promise) Error: Request failed with status code 500
    at createError (createError.js:15)
    at settle (settle.js:18)
    at XMLHttpRequest.handleLoad (xhr.js:77)

versión

"axios": "^ 0.15.3"

Hay un problema en catch : si el error ocurre antes de que se haga la solicitud, entonces en catch no tendrá la propiedad err.response , porque ... bueno ... .no hay respuesta. Entonces, catch detectará cualquier error. Lo mismo ocurre en situaciones como la de @fabiorecife cuando no hay respuesta por falla de la red. No trate el err como un error HTTP porque este no es siempre el caso.

@alsofronie, entonces, ¿cuál es el método preferido de manejo (distinguir uno de otro), por ejemplo, fallas previas al vuelo como 413?

Recibo un problema similar: las herramientas de desarrollo de Chrome muestran un 401 , la respuesta es {"message":"Identity token has expired"} y yo soy catch( (error) => {...}) , pero error.response en blanco. Me pregunto si esto se debe a que la llamada anterior OPTIONS asociada con GET tiene un estado de 200 . ¿Qué hacer en este caso y dónde está el lugar correcto para recuperar el código de estado 401 ?

@robbiemu Creo que ya está documentado: https://github.com/axios/axios#handling -errors

@mrchief gracias por esto, es bueno error.response está presente, pero los campos son undefined , cualquier llamada a valores dentro de response object da como resultado un error.

@paolavness Sugeriría abrir un nuevo tema en lugar de comentar aquí. No muchos ven problemas cerrados. O incluso preguntarlo en StackOverflow.

@mrchief Ah, esto está cerrado, gracias por señalarlo. servirá.

Tuve el mismo problema. Al final, cambié el código de error de 401 a 403 y todo funcionó como esperaba. Supongo que el motivo del objeto de error vacío y el error de JavaScript resultante tiene que ver con esta declaración que encontré en la documentación para los errores 401:

"La respuesta [un error 401] debe incluir un campo de encabezado WWW-Authenticate que contenga un desafío aplicable al recurso solicitado".

Entonces, si va a utilizar un error 401, debe incluir un campo de encabezado www-authenticate. Si no desea hacer esto, use un error 403.

Buenos días chicos, tuve este problema, sin embargo, lo arreglé cambiando mi configuración de apache para habilitar cors en mi servidor. Eche un vistazo al enlace de abajo

https://enable-cors.org/server_apache.html

Puede depurar todas las respuestas solo con console.log(JSON.stringify(error))

axios.post (url)
.entonces ((respuesta) => {
// algo
})
.catch ((respuesta) => {
if (response.status == undefined) {
alerta ('no autorizado')
}
})

Tuve exactamente el mismo problema descrito por @fabiorecife . Lo resolví pero no es la solución más elegante y no entiendo por qué es necesaria.

.catch(error=>{
let errorObject=JSON.parse(JSON.stringify(error));
console.log(errorObject);
dispatch(authError(errorObject.response.data.error));
})

Esto produce los resultados esperados en la variable errorObject .

@petruscurtu Tengo el mismo problema！ No me funciona la dosis！

No sé por qué arroja 'no Access-control-allow-origin', ¡pero el servidor lo ha configurado! El encabezado de respuesta está bien

Resuelto. El auth api no respondía el encabezado correcto que debe tener Access-control-allow-origin

@luxueyan No sé cuál podría ser el problema ya que no sé cómo maneja CORS en su servidor. En lo que respecta a axios, puedo ver una configuración y un objeto de solicitud en la salida de su consola. Creo que deberías comprobar esa salida. Puede estar relacionado con el formato de la respuesta que envía su servidor.

@luxueyan Parece que tenía su Access-control-allow-origin configurado para http://localhost:8081 (asumiendo que esto está configurado en el servidor con esta dirección http://10.31.143.32:8080 ?) ¿Puede verificar cuál es la URL que estás ejecutando este proyecto desde? ¿Es http://localhost:8081 ? Si no es así, incluso si el número de puerto es diferente, está violando las reglas de dominio de CORS.

@petruscurtu La salida es 'JSON.parse (JSON.stringify (error))' en el interceptor de respuesta. No tiene propiedad de respuesta

@chiefie Estoy seguro de que la configuración 'Access-control-allow-origin' está bien, ya que otras api ajax pueden responder al contenido correcto！ Solo la api del código capcha sale mal。 cuando expira, responde error con estado 478 y axios no puede obtener el cuerpo de respuesta！

¡Actualizar! Fue el error de la API del servidor, no tenía configuraciones de cors en el encabezado. Ahora trabaja bien.

Gracias @ juliano-barros fue por el origen cruzado. Ahora todas mis solicitudes de ajax funcionan bien.

Este error sin formato se produce siempre que el servidor no se puede alcanzar / CORS invalidado.
error.response solo será undefined .

Acabo de crear un IntegrationError que contiene datos de mensaje, estado y respuesta ... pero siempre siguiendo la misma estructura. De esta manera puedo desacoplar axios / raw error de mis manipulaciones.

Chicos de Axios, esto debería ser un error HTTP, creo ... incluyendo un error.response .
Esto se puede comprobar como se indica arriba

Ayer fue el primer aniversario de esta edición. ¿Alguna vez se "arreglará" o se considera que "no es un problema" en este momento?

@frostshoxx Así que creo que esto no es un problema. Si bien estoy experimentando el mismo problema que todos los demás, ahora entiendo lo que está sucediendo y puedo ver que esto no es un error o problema, sino simplemente la forma en que funciona el mundo.

Para todos los que están confundidos (y para celebrar este problema al cumplir un año), permítanme explicarles lo que está sucediendo y cómo obtener la respuesta de su servidor.

¿Cómo terminaste aquí?

Hay muchas razones por las que puede encontrarse con el .catch() yermo. A veces, Axios encuentra un error al principio de la solicitud. Esto sucede a veces con las solicitudes CORS. Cuando Axios OPTIONS no está disponible, Axios entra en pánico y lo envía a .catch() antes de recibir una respuesta del servidor, por lo que la respuesta no está disponible en estos casos.

Algunos de ustedes podrían decir: "No, lo veo en DevTools, ¡así que la respuesta regresó!". Esto no siempre es cierto porque a veces Axios iniciará una solicitud HTTP, experimentará un error, se abortará y lo enviará a .catch() antes de que el servidor responda. Unos milisegundos después de que Axios ejecute la función .catch() es posible que su servidor regrese con una respuesta, que aparece en DevTools porque todavía está escuchando la respuesta. Sin embargo, Axios ya ha terminado en este punto, por lo que response no estaba disponible porque no existía en el momento en que Axios inició la función .catch() .

Aquellos de ustedes que reciban un mensaje sobre un error 4XX o 5XX del servidor, ¡están de suerte! Por lo general, hay una respuesta del servidor disponible porque para obtener este error, Axios tuvo que esperar la respuesta completa del servidor. En estos casos, Axios lo envía a .catch() con response pero envuelve la respuesta en su propio objeto error que crea sobre la marcha.
Entonces, si obtiene errores 5XX o 4XX , probablemente tenga la respuesta del servidor disponible, ¡pero está enterrada PROFUNDAMENTE!

Prueba error.response.data.data.message . Se confirma que esto funciona para las solicitudes de la API de Laravel que devuelven errores del servidor.

Usuarios que no son de Laravel : al menos necesitará ir error.response.data para obtener la respuesta principal del servidor, pero la mayoría de los servidores envuelven sus respuestas en otro objeto data{} que requiere que vaya a capa más profunda, y finalmente acceda a la propiedad de respuesta que desea, como .message desde allí.

Pero lo hice Console.Log y no contiene respuesta!

Sí, lo sé, pero solo intenta generar error.response.data todos modos solo para complacerme.

Por alguna razón, Axios modifica la salida de console.log(error) en el objeto de error. No estoy seguro de por qué hacen esto, pero si en su lugar escribe console.log(JSON.stringify(error)) , verá el objeto completo en todo su esplendor.

Este es JSON serializado que se vuelve difícil de leer después de aproximadamente 2 capas de profundidad. Por lo tanto, debe copiar el elemento completo y pegarlo en un prettifyer JSON para explorar la estructura del objeto de error.

Si recibe un error 500 o un error de tipo 400 (o realmente cualquier código de error proporcionado por el servidor) en Axios, eso significa que la solicitud se completó y que la respuesta del servidor está disponible para usted.

El problema es que es muy profundo, y debido a que Axios modifica la salida de nuestro console.log(error) que la mayoría de la gente hace para ver el objeto error{} , la mayoría de la gente no sabe que existe. ¡Pero está ahí!

@ VSG24 hombre !! esa es una respuesta que salva vidas: D

fwiw, JSON.stringify(error) bombas en 0.18.0 debido a referencias circulares.

Configuré un interceptor que me da una respuesta del servidor en caso de error

axios.interceptors.response.use(
  response => {
    // do someting on response
    return response
  },
  error => {
    // do someting on errir
    return Promise.reject(error.response.data) // => gives me the server resonse
  }
)

    try {
      const { data } = await htttp.post(login, payload)
      // do someting with data
    } catch (e) {
      console.log(e) // server response data
    }

@alimirayman Parece que funciona bien si no tenemos que vigilar cada solicitud. Pero, cuando tiene que realizar un seguimiento de cada solicitud, no es razonable que se repita un controlador de errores en todas las ubicaciones de mi código. A menos que haya entendido mal (lo que puede ser el caso), ¿axios no debería tener que asegurarse de que el servidor haya devuelto un error antes de que arroje un error?

@ hhowe29 usa circular-json

Encontré este hilo como muchos otros y estoy usando axios con módulos vue.js y vuex.

La acción de mi módulo vuex detecta el error axios y ejecuta commit (ERROR_HAPPENED, error) para ejecutar la mutación ERROR_HAPPENED del módulo vuex. Pero el error llega sin su propiedad de respuesta, lo que da como resultado que error.response no esté definido si intento establecer la respuesta en un estado vuex.

Si consigo console.log (error.response) en la acción, antes del commit (), puedo ver la respuesta. Así que lo más probable es que vuex lo destroce.

Confirme (ERROR_HAPPENED, error.response.data) o verifique si es un 401 en la acción y ejecute alguna otra confirmación según el código de estado. Porque esta alteración solo ocurre con un código 401. Otros errores como 404 o 500 se transmiten a mis mutaciones.

No destrozado. Vuex no estropea esto, ni siquiera por error.
Algunos tipos de errores, principalmente dentro de los interceptores Axios, hacen que esto no quede expuesto.

¿Alguna actualización?

@AllanPinheiroDeLima lo siento por la respuesta tardía, pero no creo que nadie escriba interceptor en todas y cada una de las ubicaciones del código de nadie. Escribimos interceptor una vez en una base de código y lo usamos como una clase auxiliar, que es el número 1. Número 2, la consulta inicial fue que no obtuvieron _respuesta de error del servidor_, sino que obtuvieron el _ error de JavaScript_ en el try catch bloque. Hubo 2 soluciones, una para cambiar la forma en que el servidor respondió al error o la forma en que la interfaz detectó el error. axios interceptor de errores

Si estoy de acuerdo. Encontré una solución a este problema haciendo la integración en mi propio servidor en lugar de usar keycloak sin formato. De esta manera pude interceptar el error en el servidor y luego enviar uno legible al front-end. Creo que esa es la única forma de resolver este tipo de problema por ahora :)

Todavía tengo el mismo problema. Usando en el interceptor de Axios console.log('interceptors', JSON.stringify(error)) obtengo este registro interceptors {"config":{"transformRequest":{},"transformResponse":{},"timeout":0,"xsrfCookieName":"XSRF-TOKEN","xsrfHeaderName":"X-XSRF-TOKEN","maxContentLength":-1,"headers":{"Accept":"application/json, text/plain, */*","Content-Type":"application/json;charset=utf-8"},"method":"post","url":"http://localhost:5000/api/autenticacao/login","data":"{\"siglaInstituicao\":\"NEAS\",\"usuario\":\"emersoncpaz\",\"senha\":\"belle1903\"}"},"request":{}} pero respuesta de Chrome devtools Tengo la respuesta correcta de la api: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server) ¿Cómo obtener esta respuesta de axios?

¿Alguna razón por la que los errores 5xx no se manejan mediante el bloque catch (no devuelve un objeto de respuesta)? El código de estado 502 aparece en la consola de DevTool, pero Axios no lo maneja.

Esto funcionó para mí (con laravel abort helper: abort (500, 'message'))
''
.catch (error => {
console.log (error.response.data.message);
});

''

¿Alguien tiene un ejemplo de trabajo completo que no sea un fragmento de código que diga que esto funcionó? El recorte de 1 línea no ayuda mucho si no tiene idea de a quién se referían en este hilo, dónde pusieron ese recorte de código, ¿cómo se ve el código de trabajo final?

Estoy tratando de detectar el error en el inerceptor y, según el código de error, finalizo la solicitud allí con la redirección si 401 para iniciar sesión, o si 422 deja que la solicitud vuelva al componente de llamada para permitir la actualización de los errores del formulario.

¿Algunas ideas?

Estoy usando Nuxt axios y mi interceptor onResponseError se ve así:

$axios.onResponseError(error => {
    const code = parseInt(error.response && error.response.status)
    console.log(code, 'Axios onResponseError')
    console.log(error.response.status, 'status')
    console.log(error.config, 'config')
    console.log(error.response, 'response')
    // Do something with response error
    if (error.response.status === 401) {
      console.log('unauthorized, logging out ...')
      app.$auth.logout()
      redirect('/login')
    }
    if (code === 400) {
      // redirect('/400')
      console.log(`400 onResponseError`)
    }
    if (code === 408) {
      console.log(`A timeout happened on url onResponseError`)
    }
    if (code === 418) {
      console.log(`A teapot onResponseError`)
    }
    if (code === 428) {
      console.log(`428 onResponseError`)
      // redirect('/login')
    }
    return Promise.reject(error)
  })

Y una llamada de muestra se vería así:

async postRecord (clear = false) {
      try {
        const { r } = await this.$axios.$post(this.endPoint, this.formData)
        console.log(r, 'response')
        // do something with response
      } catch (e) {
        console.log(e, 'error in crud') // server response data
        // i should never get here if error since the interceptor should kill the request if 401
       // for testing this request is returning a 401
      } finally {
        this.submitted = false
      }
    },

Gracias,
Dave

Cuando no hay Internet, el error.response no está definido, ¿es esta la mejor manera?

Recibo un error en texto sin formato, tuve que usar lo siguiente para convertir el error en un objeto.

var errorObj = JSON.parse(JSON.stringify(error));

Esto depende del servidor y no de axios, ¿ha intentado indagar en el
error.response.status, si no está definido, entonces sabrá que es Internet
problema de conexión o un error de sintaxis en su JS

El miércoles 2 de enero de 2019, 15:40 Ibrahim Azhar Armar < [email protected]
escribió:

Recibo un error en texto sin formato, tuve que usar lo siguiente para convertir el error en
un objeto.

var errorObj = JSON.parse (JSON.stringify (error));

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/axios/axios/issues/960#issuecomment-450896476 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AEETt2r3bt2QCixDlzh4fZvWp_1rPkxuks5u_NMEgaJpZM4N9Ljl
.

@kgrosvenor Estoy poniendo el script del servidor en suspensión y espero a que axios active el tiempo de espera. Creo que el servidor en este punto no responde, por lo tanto, activa la devolución de llamada en axios.

Recibo el mensaje de error correcto, sin embargo, la consola lo muestra en texto sin formato, por lo que parece solo el problema de formato, que no parece estar relacionado con el servidor.

Si es así, estoy tratando de entender qué en el servidor podría estar causando esto.

Lo más probable es que esté agotando el tiempo de espera, intente verificar si existe una 'respuesta' en el error

axios.get()
.then(function(done) {
   //fine and can get done.data
})
.catch(function(err) {
  //catch the error, check it has a response object with lodash 
  if(_.has(err, 'response') {
     console.log(error.response.status);  
     console.log(error.response.data);
 } 
 else {
    console.log("Most likely a server timeout or an internet connection error");
    console.log("error response property is undefined")
 }
}); 

El programador de Java me envía un mensaje de error con el error 500 y no puedo manejar ese mensaje. Así que le pido que devuelva el estado 200 con un mensaje de error en respuesta, pero está enojado conmigo y dice que su cliente HTTP ve todos los mensajes con el estado 500. Él piensa que soy estúpido porque no puedo encontrar el mensaje de error con el estado 500. ¿Cómo le explico que axios no maneja el mensaje de error 500?

El programador de Java me envía un mensaje de error con el error 500 y no puedo manejar ese mensaje. Así que le pido que devuelva el estado 200 con un mensaje de error en respuesta, pero está enojado conmigo y dice que su cliente HTTP ve todos los mensajes con el estado 500. Él piensa que soy estúpido porque no puedo encontrar el mensaje de error con el estado 500. ¿Cómo le explico que axios no maneja el mensaje de error 500?

En realidad, debe poder manejar el error con el estado 500, puede verificar el estado de http en respuesta y decidir cómo manejarlo en el lado del cliente. Esto ya está documentado en este enlace (https://github.com/axios/axios#handling-errors)

Así es como detecto el error 500 del servidor y me funciona.

.catch(function (error) {
    var errorObj = JSON.parse(JSON.stringify(error));
    console.log(errorObj);
    if (errorObj.code == 'ECONNABORTED') {
        alert('Connection timed out.');
    }
});

Puede manejar el estado 500 independientemente, pero en mi opinión, es una práctica bastante mala devolverlo a propósito desde el lado del servidor ...

También recibo error.response undefined, luego intento el siguiente código.

axios.interceptors.response.use(function (response) {
  return response;
}, function (error) {
  // Do something with response error
  let {response} = error;
  // response?.status === 401 es7 way.
  if (response && response.status === 401) {
    // Do logout;
    // Redirect to login;
    return Promise.reject(error.response);
  } 
  else if (error.response){
    // Do something.
    console.log('some API_CLIENT error');
    return Promise.reject(error.response);
  }
 return Promise.reject(error);
});

Esto es una lástima, el manejo de errores es importante.

¿Cómo va ahora? ¡Sigo experimentando el mismo problema con la versión 0.18.0!

mismo problema para mí: @nuxtjs/axios v5.0.0

Es un error

Daniel Stern [email protected]于 2019 年 2 月 28 日 周四 04:39 写道 ：

Permítanme resumir esta discusión.

tl; dr:
TODOS No poder detectar errores HTTP es un problema.
DESARROLLADORES La imposibilidad de detectar errores HTTP no es un problema.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/axios/axios/issues/960#issuecomment-468020991 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAN8CbMHohyuSZHYlcieD_5yUqizpkSYks5vRuzygaJpZM4N9Ljl
.

Debe mencionar este problema en el archivo README, muy útil. ¡Gracias!

https://github.com/axios/axios/issues/960#issuecomment -320659373

Coincidiendo con otros carteles. Tener un objeto con una estructura impredecible dada a catch dependiendo del punto donde ocurre el error no es genial. Tanto error.response como JSON.stringify(error) pueden producir errores dependiendo de la causa. El enfoque sugerido en https://github.com/axios/axios#handling -errors tampoco es precisamente esclarecedor en esto.

Tener que hacer todas estas acrobacias para devolver un maldito mensaje de error es vergonzoso en 2019. Hubiera sido vergonzoso en 1990. En serio, gente de JS, mejoren su juego. Aprenda algo de diseño de API y reconozca que sus 'decisiones creativas' le cuestan a miles de personas innumerables horas depurar un desastre que está ignorando deliberadamente.

Para aquellos que luchan con las referencias circulares, puede hacer algo como esto:

try {
// your axios request
} catch (error) {
  const { response } = error;
  const { request, ...errorObject } = response; // take everything but 'request'
  res.status(response.status);
  return res.json(errorObject); // or use 'return res.json(response.data.error);' then you don't need to omit the 'request'
}

Para aquellos que luchan con las referencias circulares, puede hacer algo como esto:

try {
// your axios request
} catch (error) {
  const { response } = error;
  const { request, ...errorObject } = response; // take everything but 'request'
  res.status(response.status);
  return res.json(errorObject); // or use 'return res.json(response.data.error);' then you don't need to omit the 'request'
}

¡Gracias amigo! su código funcionó bien para mí.

El problema está en "lib / core /hanceError". El objeto de solicitud se agrega al error. Tiene sentido agregar una respuesta a la respuesta, ya que solo hay un parámetro en las API basadas en promesas (la biblioteca de solicitudes devuelve un error como primer parámetro y una respuesta como segundo). Pero no tiene sentido agregar toda la solicitud. El cambio de código es muy simple https://github.com/geoblink/axios/pull/1/files
Podría abrir pr a la rama principal si parece importante (no lo estoy haciendo ya que el problema está cerrado)

puede hacer un contenedor de funciones al que llamará cada vez que realice solicitudes

const api = async (uri, data) => {
  try {
    const { data: response } = await axios({
      url: domain + uri,
      method: 'POST',
      data,
    });

    return response.data;
  } catch (error) {
    throw error.response.data;
  }
};

Lo más probable es que esté agotando el tiempo de espera, intente verificar si existe una 'respuesta' en el error

axios.get()
.then(function(done) {
   //fine and can get done.data
})
.catch(function(err) {
  //catch the error, check it has a response object with lodash 
  if(_.has(err, 'response') {
     console.log(error.response.status);  
     console.log(error.response.data);
 } 
 else {
    console.log("Most likely a server timeout or an internet connection error");
    console.log("error response property is undefined")
 }
}); 

Esto funcionó para mí. Gracias

el uso de "error.response" no funciona, para mí. El problema ocurre cuando desconecté el servidor de la base de datos y mi servidor web devolvió el error 500.

Pestaña de red en herramientas de desarrollo

código de respuesta: 500
cuerpo de respuesta:

{
  "error": {
    "statusCode": 500,
    "name": "Error",
    "message": "read ETIMEDOUT",
    "code": "ETIMEDOUT",
    "errno": "ETIMEDOUT",
    "syscall": "read",
    "stack": "Error: read ETIMEDOUT\n    at exports._errnoException (util.js:1050:11)\n    at TCP.onread (net.js:582:26)"
  }
}

error de la consola de Chrome:

Uncaught (in promise) Error: Request failed with status code 500
    at createError (createError.js:15)
    at settle (settle.js:18)
    at XMLHttpRequest.handleLoad (xhr.js:77)

versión

"axios": "^ 0.15.3"

AQUÍ IGUAL...

En mi experiencia:

"Modifique de console.log (error) a console.log (error.response) en la captura".

funcionó mejor con console.log (error.response.data) en la captura.

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

getClients: async (estado) => {
const res = aguardar axios.get ( ${BASE_API}/clients );
console.log ('res', res);
if (res) {
state.commit ("setClient", res.data);
}
}

Otra opción

/**
 * Whenever error.message is accessed we want to se the full API error message (JSON) if it's present
 * not just some generic http status code + message
 * see https://github.com/axios/axios/issues/960 for context
 *
 * <strong i="6">@param</strong> axios
 */
export function extractAPIErrorResponse(axios: AxiosInstance) {
    axios.interceptors.response.use(undefined, function (error: AxiosError) {
        (error as any).originalMessage = error.message;
        Object.defineProperty(error, "message", { get: function () {
            if (!error.response) {
                return (error as any).originalMessage;
            }
            return JSON.stringify(error.response.data);
        }});
        return Promise.reject(error);
    })
}

Tratar{
Espera esto. $ Axios .....
} captura (e)
{
console.log (e)

}

axios.get("https://......") 
     .then( response => {
          return response
}).catch( () => {
         store.dispatch("errorComponentMethod")   // if there's an error, method is dispatched
})
//////////////////////////////////////
actions : {
      errorComponentMethod(){
              router.push("/errorComponent")     // method routes to error component
      }
}

Muchas gracias ! ¡Ayudó mucho!

todavía tengo este problema. en el depurador de Chrome, la respuesta es correcta pero axios devuelve un "Request failed with status code 403" lugar

Todavía tengo esto y estoy realmente confundido. Intenté captarlo en los comentarios anteriores, pero ¿por qué exactamente axios devuelve indefinido cuando hay un error?
try{ const res = await axios.get("someurl"); return res; } catch(e) { console.log(e); }
res no está definido a pesar de que el servidor está enviando una respuesta con un mensaje de POR QUÉ no funcionó. Y no puedo acceder a esos datos ... ¿por qué?

** EDITAR: encontré mi error, nada malo para mí con axios. Vea mi comentario dos comentarios hacia abajo. En resumen, mis interceptores no pasaban los datos de error a través de la tubería de axios, por lo que siempre me quedaba indefinido.

@HoogsterInc Eche un vistazo a las definiciones de TypeScript aquí
podrías hacer algo como esto

try {
   axios.get(...)
} catch (error) {
   if (error.reponse) {
      // http status 4x, 5xx
   } else {
      // network error like timeout, connection refused etc...
   }
}

Gracias por la respuesta tratando de ayudar a @konstantinblaesi :

Para mí, tenía un interceptor configurado para verificar la autenticación del usuario, que si se desautoriza, envía un código de error específico. Sin embargo, no estaba transmitiendo los datos del error cuando el error no coincidía con un código no escuchado ... suspiro ... error tonto. Entonces, después de verificar el código de error no autenticado, me aseguré de devolver Promise.reject (error); - Eso resolvió mi problema y los datos de error ahora vienen completos.

Puedes usar err.toJSON()

catch((err) => {
    console.log(err.toJSON()); // Return error object
});

https://github.com/axios/axios#handling -errors

(configurado para global)

en el main.js

import axios from 'axios'

var instance = axios.create(
 { validateStatus: function (status) {
    return status < 600; #you can change this with another value
  }
 });

o
(fijado para particular)

  axios.post('/formulas/create', {
       name: "",
       parts: ""
  }, { validateStatus: function (status) {
          return status < 600; // Reject only if the status code is greater than or equal to 500
        }})
    .then( 
   (response) => { console.log(response) },
   (error) => { console.log(error) }
   );

Datos de respuesta de error de Axios & catch 500

const log = console.log;

  updateData(options = {}, flag = false){
    let url = `/opapi/appDownloadGuide/update`;
    let message = '更新成功!';
    let errorMessage = '更新失败!';
    if (flag) {
      message = '添加成功!';
      errorMessage = '添加失败!';
      url = `/opapi/appDownloadGuide/add`;
    }
    axios
    .post(url, options)
    .then(res => {
      // ❓🤔️500 , 在这里拦不住呀？
      log(`res`, res, res.status);
      return res.data;
    })
    .then(json => {
      const {
        code,
        success,
        data,
        errorCode,
        errorHint,
      } = json;
      if(code === 200) {
        this.$message({
          type: 'success',
          message,
        });
        this.init();
      } else{
        this.$message({
          type: 'error',
          message: `${errorMessage}: ${errorHint ? errorHint : ""}`,
        });
      }
    })
    .catch(err => {
      // 👌在这里拦截 error data!
      log(`error.response`, err.response);
      const {
        data,
        status,
        statusText,
      } = err.response;
      this.$message({
        type: "error",
        message: `${statusText}-${status}: ${data || ""}`,
        // message: "不能重复创建",
      });
      console.error(`500 err`, err);
    });
  },

https://stackoverflow.com/questions/38798451/how-to-catch-and-handle-error-response-422-with-redux-axios

Tengo exactamente el mismo entorno. Prueba esto:

axios.post('/formulas/create', {
  name: "",
  parts: ""
})
.then(response => { 
  console.log(response)
})
.catch(error => {
    console.log(error.response)
});

_Modifica de console.log(error) a console.log(error.response) en catch _.

También puede usar un interceptor global y rechazar solo error.response . El problema es que cuando console.log intenta mostrar el error, se imprime la representación de la cadena, no la estructura del objeto, por lo que no ve la propiedad .response .

No funciona para mi

@ gopal-g no está definido para mí.

@ gopal-g sí lo mismo indefinido que estoy obteniendo.

Estoy usando Axios 0.19.2. Agregué la solución de

Otra opción

/**
 * Whenever error.message is accessed we want to se the full API error message (JSON) if it's present
 * not just some generic http status code + message
 * see https://github.com/axios/axios/issues/960 for context
 *
 * <strong i="9">@param</strong> axios
 */
export function extractAPIErrorResponse(axios: AxiosInstance) {
    axios.interceptors.response.use(undefined, function (error: AxiosError) {
        (error as any).originalMessage = error.message;
        Object.defineProperty(error, "message", { get: function () {
            if (!error.response) {
                return (error as any).originalMessage;
            }
            return JSON.stringify(error.response.data);
        }});
        return Promise.reject(error);
    })
}

Esto funcionó para mí, ¡muchas gracias @konstantinblaesi ! No entiendo por qué el comportamiento predeterminado de Axios no es así: el comportamiento estándar es eliminar la parte del "mensaje" del error original, que creo que es la parte más importante.

Para que quede claro, en mi aplicación, mi servidor devuelve un error 400 (que debería ser una respuesta):

% curl -X POST http://my-server/api -d '{"foo": "bar"}'
{"status": 400, "message": "missing param XYZ"}

y sin esta solución, obtengo de Axios un objeto de error que contiene solo name , stack , config (que tiene la solicitud original) y ninguna "respuesta". Pero con esta solución, el error contiene la propiedad message correcta del servidor.

En cuanto a por qué no hay una propiedad de "respuesta" sin esta corrección, parece estar relacionada con settle en axios.js alrededor de la línea 1171:

        module.exports = function settle(resolve, reject, response) {
          var validateStatus = response.config.validateStatus;
          if (!validateStatus || validateStatus(response.status)) {
            resolve(response);
          } else {
            reject(createError(
              'Request failed with status code ' + response.status,
              response.config,
              null,
              response.request,
              response
            ));
          }
        };

y puede ver que no pasa por response.message al crear el error. Además, en mi aplicación no veo la respuesta en error.response , no existe tal propiedad, no lo entiendo. Pero de todos modos, la solución anterior funciona para mí.

Estoy tratando de detectar errores de validación del servidor.

Código:

axios.post('/formulas/create', {
       name: "",
       parts: ""
})
.then( 
  (response) => { console.log(response) },
  (error) => { console.log(error) }
);

Salida del registro de la consola

Error: Request failed with status code 422
    at createError (app.js:6765)
    at settle (app.js:29489)
    at XMLHttpRequest.handleLoad (app.js:6600)

Salida de la pestaña de red
{"nombre": ["El campo de nombre es obligatorio"], "partes": ["El campo de piezas es obligatorio".]}

Debería ver un objeto que contiene la validación del formulario JSON, ya que esa es la respuesta en mi pestaña de red, ¿parece que obtengo el resultado de captura de JS?

También probé lo siguiente:

axios.post('/formulas/create', {
  name: "",
  parts: ""
})
.then(response => { 
  console.log(response)
})
.catch(error => {
    console.log(error)
});

Mismo resultado

Más personas parecen tener el mismo problema usando el mismo entorno que yo aquí.
https://laracasts.com/discuss/channels/vue/issues-with-axios-catch-method

• Versión de Axios: ^ 0.16.2
• VueJS 2.3.4
• Vue-template-compiler 2.3.4
• Laravel-mix
• Entorno: nodo v6.4.0, chrome 58, Mac OSX 10.12.4

axios.post ('/ formulas / create', {
nombre: "",
partes: ""
})
.entonces(
(respuesta) => {console.log (respuesta)},
) .catch (err => consol.log (err.response.data)});

error.response es un objeto, generará [objeto, objeto] en el registro de la consola.
tienes que usar error.reposne.data para acceder al mensaje de error.
consulte: https://itnext.io/javascript-error-handling-from-express-js-to-react-810deb5e5e28

@chandukasm sí, pero en mi caso _no_ tengo un error.response - no está definido, a pesar de que la solicitud fue enviada y la respuesta recibida por expreso. También vea mi comentario arriba; el mensaje se ignora (se reemplaza por un mensaje genérico) incluso cuando existe una respuesta.

error.response es un objeto, generará [objeto, objeto] en el registro de la consola.
tienes que usar error.reposne.data para acceder al mensaje de error.
consulte: https://itnext.io/javascript-error-handling-from-express-js-to-react-810deb5e5e28

si ve [objeto, objeto] en console.log, simplemente haga JSON.stringify (error.response) para ver el error real.

No hay ningún objeto error.response .

return this.$axios
  .post(postUrl, payload, { responseType: 'json' })
  .then(
    (response) => {
      this.message = `RESP: ${JSON.stringify(response)}`;
    },
    (reason) => {
      this.message = `REAS: ${JSON.stringify(reason)}`;
    }
  )
  .catch((err) => {
    this.message = `CATCH: ${JSON.stringify(err)}`;
  });

payload contiene un valor incorrecto a propósito para activar HTTP 422, que en Postman funciona como se esperaba y el servidor (LB4) devuelve un error completo en formato JSON que explica dónde estaban incorrectos los datos de entrada, pero en axios, el objeto error.response no está definido .