Escape from uncaught exceptions for IDEs

[EricssonXD]

I faced the same issue as #314 and #1869, and I also understand that it is not an error with the dio package but an error with the Flutter SDK / VScode, where VScode does not recognise the exceptions as handled when using Future.catchError().

Despite it not being a problem of this package, I believe "fixing" it such that it avoids the above mentioned problem is still the correct approach, the following modification avoids this problem, and allows the example Error Handling code on pub.dev works with VScode.

New Pull Request Checklist

• I have read the Documentation
• I have searched for a similar pull request in the project and found none
• I have updated this branch with the latest main branch to avoid conflicts (via merge from master or rebase)
• I have added the required tests to prove the fix/feature I'm adding
• I have updated the documentation (if necessary)
• I have run the tests without failures
• I have updated the CHANGELOG.md in the corresponding package

Additional context and info (if any)

[AlexV525]

@EricssonXD Hi, thanks for taking the time to investigate the cause. Very much appreciated!

I was wonder if adding the paired async/await could be addressed by simply adding return to the _dispatchRequest. WDYT?

[AlexV525]

Could also help to identify if this is relevant fix for #1869?

[EricssonXD]

Could also help to identify if this is relevant fix for #1869?

@AlexV525 I forgot to mention it in the description, this is also an issue that I came across which is the exact problem I ran into initially

[EricssonXD]

@EricssonXD Hi, thanks for taking the time to investigate the cause. Very much appreciated!

I was wonder if adding the paired async/await could be addressed by simply adding return to the _dispatchRequest. WDYT?

As the function is a parameter that gets passed to the interceptor, which expects a void Function(RequestOptions options, RequestInterceptorHandler handler), it cannot return any value. Unless we also modify the interceptor? Although I wouldn't suggest it as it seems like a lot more work and might lead to other unexpected problems

[EricssonXD]

@EricssonXD Hi, thanks for taking the time to investigate the cause. Very much appreciated!

I was wonder if adding the paired async/await could be addressed by simply adding return to the _dispatchRequest. WDYT?

Is there any reasons why you would like to avoid async/await? From what I see in how the code is used, I don't think there should be any difference in terms of performance. But I'm still new to Flutter, so correct me if I'm wrong.

[AlexV525]

Is there any reasons why you would like to avoid async/await? From what I see in how the code is used, I don't think there should be any difference in terms of performance. But I'm still new to Flutter, so correct me if I'm wrong.

You may spot that we've already implemented .then and .catchError for the method. Theoretically, all exceptions should be caught here. Awaiting a future that is not void is not recommended.

Consider writing like this:

[EricssonXD]

That's actually what I wrote initially during debugging but I found out adding only the await keyword somehow made it work which lead to my proposed code. I have updated my code now, but I don't quite understand what do you mean by

Awaiting a future that is not void is not recommended.

Isn't this new code also awaiting a future that is not void? Or do you mean like we shouldn't await a value that is not void if we are not using it?

[AlexV525]

That's actually what I wrote initially during debugging but I found out adding only the await keyword somehow made it work which lead to my proposed code. I have updated my code now, but I don't quite understand what do you mean by

Awaiting a future that is not void is not recommended.

Isn't this new code also awaiting a future that is not void? Or do you mean like we shouldn't await a value that is not void if we are not using it?

What I mean is we shouldn't wait for a future that returns value but not use it eventually.

In general:

Future<String> foo() async {
  await Future(() {});
  return 'bar';
}

void main() async {
  // Good.
  final result = await foo();
  print(result);

  // Bad.
  await foo();
}

[EricssonXD]

Ahhh I see, are there any more problems that I should address in my pull request?

[AlexV525]

One nit:

[AlexV525]

I'd consider the request as test exempt, as it doesn't affect any actual behavior. Waiting for other inputs.

[AlexV525]

@kuhnroyal @ueman Any inputs?

[AlexV525]

Going to merge this and apply inputs if any in the future.

[kuhnroyal]

I think the fix for the root cause is out in Dart:master now. But this looks cleaner in any case.
We should try to avoid then & catchError in all new could just for readability.