You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
DioException.toString() should contain the request information #1949
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:
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.
changed the title [-]`DioException` should contain the request information[/-][+]`DioException.toString()` should contain the request information[/+]on Sep 3, 2023
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.
Activity
kuhnroyal commentedon Sep 1, 2023
The request information is available via
exception.requestOptions. You can build your own extension function to print a customized message.iota9star commentedon Sep 2, 2023
The
requestOptionsfield is useful, but not relevant to the actual error message.A friendly error message,
toStringmethod 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.[-]`DioException` should contain the request information[/-][+]`DioException.toString()` should contain the request information[/+]ueman commentedon Sep 6, 2023
@iota9star Are you willing to contribute this as a PR?
kuhnroyal commentedon Sep 15, 2023
Can we always print the URL, are there any possible privacy concerns if we omit query parameters?
iota9star commentedon Sep 16, 2023
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 commentedon Sep 16, 2023
This is too difficult for me.
brian030128 commentedon Sep 30, 2023
Doesn't writing your own error log interceptor allow this?
dio/dio/lib/src/interceptor.dart
Lines 200 to 206 in 4d7ea68
nottmey commentedon Feb 15, 2024
@ueman Hi Jonas, would this be a valid approach? Any concerns?
AlexV525 commentedon Sep 18, 2024
I've filed 2 PRs to find out if there is a better answer for the issue. Please vote or add comments if you'd like to.
DioExceptionLogLevel#2296DioExceptionReadableStringBuilder#2297✨ Introduce `DioExceptionReadableStringBuilder` (cfug#2297)
✨ Introduce `DioExceptionReadableStringBuilder` (#2297)
✨ Introduce `DioExceptionReadableStringBuilder` (cfug#2297)