DioException.toString() should contain the request information

[iota9star]

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

[kuhnroyal]

The request information is available via exception.requestOptions. You can build your own extension function to print a customized message.

[iota9star]

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.

[ueman]

@iota9star Are you willing to contribute this as a PR?

[kuhnroyal]

Can we always print the URL, are there any possible privacy concerns if we omit query parameters?

[iota9star]

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]

@iota9star Are you willing to contribute this as a PR?

This is too difficult for me.

[SpeedReach]

Doesn't writing your own error log interceptor allow this?

dio/dio/lib/src/interceptor.dart

Lines 200 to 206 in 4d7ea68

	/// Called when an exception was occurred during the request.
	void onError(
	DioException err,
	ErrorInterceptorHandler handler,
	) {
	handler.next(err);
	}

[nottmey]

@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);
  }
}