dio
dio copied to clipboard
cfug
`DioException.toString()` should contain the request information
Request Statement
When printing exception information, it is impossible to quickly locate the source of the request. Here are some examples:
DioException [connection timeout]: The request connection took longer than 0:00:30.000000. It was aborted.
The exception message only shows that a connection timeout occurred, but does not provide any information about which request timed out. This makes it difficult to quickly identify the problematic request when debugging.
Some additional context that would be useful:
The URL of the request The HTTP method (GET, POST, etc) Any identifiers like request ID So a more helpful exception could be:
DioException [connection timeout]: GET https://example.com/api/v1/users took longer than 30s and was aborted.
By including details like the URL and request method in the exception, it becomes much faster to pinpoint where the problem is occurring.
Solution Brainstorm
No response
The request information is available via exception.requestOptions. You can build your own extension function to print a customized message.
The requestOptions field is useful, but not relevant to the actual error message.
A friendly error message,toString method should contain concise, accurate and effective information. For example, now I have a method that contains some Dio requests, and some other methods that may also throw errors. Normally, I only need to call print to meet the need when I want to print the exception information, but now I need to first judge if the current error is a DioException, then extract useful information from it, and customize the message according to the error type. This obviously introduces a lot of burden. Of course, I can also write an extension method to unify custom message assembly to reduce boilerplate code, but this obviously has a huge mental overhead when I have many methods.
Can we always print the URL, are there any possible privacy concerns if we omit query parameters?
Appropriately outputting additional information does not pose much of a problem. Request method, request path and such do not have major privacy issues. Error messages are controlled by developers, and leaks are only individual developer's problems. Of course we can also try printing exception information at different levels through configuration.
@iota9star Are you willing to contribute this as a PR?
This is too difficult for me.
Doesn't writing your own error log interceptor allow this?
https://github.com/cfug/dio/blob/4d7ea685bd9de004bffe276e24e966400b98e818/dio/lib/src/interceptor.dart#L200-L206
@ueman Hi Jonas, would this be a valid approach? Any concerns?
class ErrorMessageRewritingInterceptor extends Interceptor {
@override
void onError(DioException err, ErrorInterceptorHandler handler) {
final errWithHelpfulMessage =
err.copyWith(message: '<some helpful message for debugging>');
super.onError(errWithHelpfulMessage, handler);
}
}
