-
-
Notifications
You must be signed in to change notification settings - Fork 10.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refine arguments for error interceptors #2553
Conversation
@@ -120,7 +120,7 @@ export interface CancelTokenSource { | |||
} | |||
|
|||
export interface AxiosInterceptorManager<V> { | |||
use(onFulfilled?: (value: V) => V | Promise<V>, onRejected?: (error: any) => any): number; | |||
use(onFulfilled?: (value: V) => V | Promise<V>, onRejected?: (error: V) => any): number; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A successful callback should return V(AxiosResponse), but when there is an error, maybe it should return AxiosError
insteadof V
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure about AxiosError
?
Actually I think there will be no problem even if I don’t change it. |
Sorry, we don't know which type the error is. Because it can be thrown from anywhere. |
@chinesedfan can we improve the type annotation by writing |
@xamgore You can use a type assertion(#2013 (comment)) or contribute a type guard(#1863). In fact, I like type guard better. |
Type assertion requires a hidden knowledge of On the other hand if export interface AxiosInterceptorManager<V> {
- use(onFulfilled?: (value: V) => V | Promise<V>, onRejected?: (error: V) => any): number;
+ use(onFulfilled?: (value: V) => V | Promise<V>, onRejected?: (error: AxiosError | any) => any): number;
eject(id: number): void;
} |
@xamgore |
Typescript documentation has a similar case: They define two interfaces, possibly intersecting: interface Bird {
fly();
layEggs();
}
interface Fish {
swim();
layEggs();
}
function getSmallPet(): Fish | Bird {
// ...
}
let pet = getSmallPet();
pet.layEggs(); // okay
pet.swim(); // errors
pet?.layEggs(); // okay
pet?.swim(); // okay, though swim() wasn't called Then they provide a user type-guard: function isFish(pet: Fish | Bird): pet is Fish {
return (pet as Fish).swim !== undefined;
}
if (isFish(pet)) pet.swim() // ok In our case |
I know that official example. And just thought |
Using function assertIsAxiosError<T>(err: any): asserts err is AxiosError<T> {
if (err.isAxiosError) {
throw new AssertionError("Not an AxiosError!");
}
}
// in onRejected function
// type Data = { x: number };
try {
assertIsAxiosError<Data>(err);
console.log(err.response?.data.x); // err: AxiosError<Data>
} catch {
console.log(err); // err: any
} I would be happy if this information is helpful for you. |
Any is not really a good type for error handling. I believe they should be Request / Response objects.