Improve axios stack traces

Currently, if you use axios with async / await, you get a stack trace like this:

Request failed with status code 500
    at createError (/Users/rmenezes/code/seedfi/web/node_modules/axios/lib/core/createError.js:16:15)
    at settle (/Users/rmenezes/code/seedfi/web/node_modules/axios/lib/core/settle.js:17:12)
    at IncomingMessage.handleStreamEnd (/Users/rmenezes/code/seedfi/web/node_modules/axios/lib/adapters/http.js:237:11)
    at IncomingMessage.emit (events.js:208:15)
    at IncomingMessage.EventEmitter.emit (domain.js:471:20)
    at endReadableNT (_stream_readable.js:1154:12)
    at processTicksAndRejections (internal/process/task_queues.js:77:11

It doesn’t show you much about what called Axios., which makes debugging quite difficult!

This is because settle calls createError: https://github.com/axios/axios/blob/master/lib/core/settle.js#L12-L24

Which creates a new error with a brand new stack trace: https://github.com/axios/axios/blob/master/lib/core/createError.js#L15-L18

Perhaps we can fix this by creating an error before the request goes out and stitching it to the new error’s stack trace?

[Frondor]

Please use the interceptor approach mentioned above, we will address this in the future however currently an interceptor is the most appropriate solution.

Hi @jasonsaayman, I see this issue brings lots of headaches and a bad developer experience to those who fall into these scenarios without any knowledge about the need of such interceptor.

I don’t think that’s the best solution and imho, it degrades Axios as a good library for production-ready applications.

A fix should be as easy as implementing something like

https://github.com/axios/axios/blob/5bc9ea24dda14e74def0b8ae9cdb3fa1a0c77773/lib/core/createError.js#L16-L17

to

var axiosError = enhanceError(new Error(message), config, code, request, response);
if (Error.captureStackTrace) Error.captureStackTrace(axiosError, createError);
return axiosError;

Yes, it MAY degrade performance (imo its negligible) for failing requests, but we all know this is better than having no input for proper debugging.

I can open a PR with this and discuss the approach if you want.

[jmicco]

This makes it super hard to debug bad responses from other servers when you are making lots of calls.