Skip to content
This repository has been archived by the owner on Feb 13, 2023. It is now read-only.

Improve DioErrors #16

Merged
merged 7 commits into from
Nov 8, 2022
Merged

Improve DioErrors #16

merged 7 commits into from
Nov 8, 2022

Conversation

ueman
Copy link
Contributor

@ueman ueman commented Nov 4, 2022

Originally proposed in cfug/dio#1405

Changes are already being covered by existing tests.

Copy link
Member

@AlexV525 AlexV525 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that we want to release these changes into 5.0, a breaking change would be acceptable. It still needs to provide migrations.

dio/lib/src/dio_error.dart Outdated Show resolved Hide resolved
if (error != null) {
msg += '\nError: $error';
}
if (error is Error && error.stackTrace != stackTrace) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer to hide stack traces from when describing a DioError, WDYT?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you prefer it?

I would prefer to get rid of the wrapping of exceptions, which is the cause of it. But as long as the wrapping of exceptions is done, the inner stacktrace might be helpful for debugging, so it should be included in the message. Otherwise, there's no way to get that stacktrace when using error monitoring tools.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because it holds the stack trace. The stack trace can be accessed as a field of DioError, rather than wrapped into a describing method. Consider we have an exception handler, so we can do if (error is DioError) stackTrace = error.stackTrace. You'll usually report exceptions so the report will contain duplicate stack traces.

dio.get('/fakepath3').catchError((e) => throw (e as DioError).message),
throwsA('test error'),
dio.get('/fakepath3').catchError((e) => throw (e as DioError)),
throwsA(isA<DioError>()),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might use .having to obtain the previous error message.

}
rethrow;
} on TimeoutException {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it necessary to remove this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the exceptions are now thrown in the future.timeout(...) callback, no TimeoutException is thrown.

If onTimeout is omitted, a timeout will cause the returned future to complete with a TimeoutException.

See https://api.dart.dev/stable/2.18.4/dart-async/Future/timeout.html

),
StackTrace.current,
);
xhr.abort();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checking around the code again, should we return the closure here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think that makes sense.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We might figure out a proper test for this, but no need to rush.

Copy link
Member

@AlexV525 AlexV525 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dashatar

@ueman ueman merged commit 090f18f into main Nov 8, 2022
@ueman ueman deleted the improve-dio-errors branch November 8, 2022 08:43
@AlexV525
Copy link
Member

This also fixes cfug/dio#1498.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants