Open WutangNailao opened 1 year ago
This makes a lot of sense.
I think we either should properly wrap the exception, or we shouldn't wrap it at all.
I think we do.
Just from looking at the screens, the reported exception probably originated at the jsonDecode
.
These (#1949) are quite similar which requires a nicer first-look regarding the exception.
Adding request information to the exception is one thing. Figuring out a sensible way to convert arbitrary exceptions/objects into strings is another. Any ideas for this? We call toString()
on the inner error but we don't always pass a message to the DioException
- that is why it says [unknown]: null
.
DioException
has a error field, this is probably what you're looking for?
https://github.com/cfug/dio/blob/4d7ea685bd9de004bffe276e24e966400b98e818/dio/lib/src/dio_exception.dart#L176-L178
Based on the above comments, the root cause of the exception is the JSON fails to be decoded before it reaches your exception, so a FormatException
was thrown. Otherwise, it would be DioException(APIException)
.
Closing as it's working as intended.
it's my wrong, i show a wrong example. this is a good example i think for my issue.
when i get a response with code 401, i throw a apiexception, in the terminal, i see which i throwed apiexception, but it wrapped with dioException, so i can't not catch this error exactly next time.
Not sure how we can achieve that other than the developer registering custom types somewhere.
Has there been no progress on this issue?
Request Statement
When i write a interceptor class extends Interceptor, in some case, i wish throw some exception to tell the developer some thing went wrong. so i throw a custom exception in override function 'onResponse', but this exception was catched by DioException, and this exception can not tell me more infomation about this error.
So, i wish this will be supported
Solution Brainstorm
No response