Axios rejects error with Error type. Adding custom error type will help with distinguishing between axios and other errors. The only way now is to check 'request' field existence which is not always possible. Our internal custom error type has this field too.
const { axios, AxiosError } = require('axios');
...
try {
...
const response = await axios.get(url);
...
} catch (error) {
if(error instanceof AxiosError) {
return processAxiosError(error);
}
throw error;
}
Relates to: #24
This would be simple enough to do, but would be a breaking change.
AxiosError has to inherit from Error. This wouldn't breaking change.
It would be if someone is checking error.constructor.name === 'Error'
I agree but this is a minor breaking change. Can we sacrifice this for better API?
I'm in favor of this, but personally I would prefer, if the maintainers agree ofcourse, that we bump axios to a semver, v1.0.0
Axios certainly seems stable enough for that, and following semver-major prevents breakage.
On another note, given the widespread use of axios and the preferred HTTP library of React and Vue.js, a breaking change can have major impacts which need to be considered.
Actually, now that I checked, axios is working on a v1.0.0 branch, I might open a PR for this today.
@mzabriskie, @nickuraltsev
@JustinBeckwith
/cc @Khaledgarbaya @axe312ger @zcei
Ohh yes, this would help a lot. Having kinda the same issue in our SDK.
Can we add this to #1333 @Khaledgarbaya?
The PR is already there, I added a soft fix for the 0.x versions as a flag in #1419, and the Error type change for the 1.x in #1420, refer the linked PRs
@axe312ger @Khaledgarbaya any updates on this?
@axe312ger any update please?
Have to pass on to @Khaledgarbaya 馃槄
This would be wonderful. Running into this issue now!
Is there any progress on this issue? It's useful to distinguish axios errors from other errors. And adding isAxiosError flag to errors thrown by axios https://github.com/axios/axios/pull/1419 is a good solution without breaking changes. Consider adding this flag in a patch version please?
+1
@Khaledgarbaya any updates on this?
I still like this, as we all have jobs, feel free to contribute that as PR
@axe312ger We already have 2 PRs for 5 months!
Oops. Hard to keep track on this repo.
I'd prefer https://github.com/axios/axios/pull/1419 to end up in master since the v1 rewrite currently is kinda frozen due to lack of time on our side.
Can you resolve conflicts and mention some people in there?
This is now fixed in https://github.com/axios/axios/pull/1419
That was fast :)
That was open source:)
The power of GitHub mentions :trollface:
@axe312ger @Khaledgarbaya is it too soon to request a release please?
@AyushG3112 Unfortunately I don't have npm release rights
@nickuraltsev @emilyemorehouse is there a plan releasing this anytime soon?
I think if it is implemented, it will be more practical and clearer than using
@axe312ger @Khaledgarbaya @nickuraltsev @emilyemorehouse can any of you please @-mention someone with npm publish rights?
AxiosError would've been nicer... Can someone publish the isAxiosError change, please?
Because at least we need some type-guard-aware function like function isAxiosError(error: Error): error is AxiosError { return !!error.isAxiosError }
, it might be better to have it in library side.
@Khaledgarbaya @axe312ger It's been months, can we have a release please?
We have no rights to publish axios to npm
Could you tag someone who does please?
You did yourself last December https://github.com/axios/axios/issues/1415#issuecomment-449578470 - Nick and Emily have publish rights.
馃憢 I've been handling all releases for consistency. As soon as CI is green again, I'll release!
Most helpful comment
This is now fixed in https://github.com/axios/axios/pull/1419