28

In a relatively simple block of code that checks an API endpoint (determining connection state), I rely on a try..catch as the mechanism to validate if the application can communicate with the server.

The issue I'm having is that while debugging, the debugger always stops on the connection line (when the application is offline) even though I am handling the errors internally.

  Future<bool> isOnline() async {
    try {
      // VSCode debugger always stops on this line when no connection
      await http
          .get('${consts.apiBaseUrl}/api/ping')
          .timeout(Duration(seconds: normalTimeoutLength))
          .catchError(
        (_) {
          // Trying catchError on the Future
          _isOnline = false;
          return false;
        },
      );
      _isOnline = true;
      return true;
    } on HttpException catch (_) {
      // Trying to catch HTTP Exceptions
      _isOnline = false;
      return false;
    } on SocketException catch (_) {
      // Trying to catch Socket Exceptions
      _isOnline = false;
      return false;
    }
  }
TheGeekZn
  • 3,696
  • 10
  • 55
  • 91

3 Answers3

19

Here is a supplemental image (VS Code) to the Danny's answer:

enter image description here

Suragch
  • 484,302
  • 314
  • 1,365
  • 1,393
18

This is a limitation of the Dart VM. It does not correctly detect exceptions that are caught with catchError() so it causes the debugger to pause on them. There's some discussion about this here:

https://github.com/flutter/flutter/issues/33427#issuecomment-504529413

If you click Continue/Resume there should be no difference in behaviour, but as a workaround you could convert the code to use real try/catch instead of catchError() or untick the option in the Debug side bar to break on uncaught exceptions (though obviously this will affect real uncaught exceptions too - although in Flutter they're not too common since the framework catchs most exceptions).

Danny Tuppeny
  • 40,147
  • 24
  • 151
  • 275
  • 3
    Thanks for the reply - it's good to see issues like this actually on the radar (even if it takes a while to fix). What this example doesn't show is me wrapping in a normal `try...catch` but that yields the same result unfortunately. I'm using your workarounds with only minor caveats – TheGeekZn Jul 06 '19 at 14:05
  • Which version of Flutter are you using? Can you repro on the `beta` channel or later? I think there was a bug in the `try/catch` version that was fixed too, but it's probably not in Flutter stable yet. If you can still repro in `beta` and can make a small example using try/catch, it's worth opening an issue in the dart-lang/sdk repo for some investigation. – Danny Tuppeny Jul 06 '19 at 21:23
  • I'm basically always up to date on the `dev` branch. Maybe it'll be worthwhile to open a bug I'll check over today if it's still happening with the latest flutter dev build and revert. – TheGeekZn Jul 15 '19 at 06:55
  • I'm facing this issue as well on stable channel, v1.17.1 – Sameen May 31 '20 at 14:40
  • 1
    Still happening on 1.17.3 - disabling breakpoints until it successfully does a `try` has been my current solution. – KoalaZub Jun 17 '20 at 03:04
  • If you're still seeing bad behaviour, please file a bug and include a code repro. Thanks! – Danny Tuppeny Jun 17 '20 at 07:16
14

If you are looking to bypass the exception(s) so the app doesn't stop, you can untick the "Uncaught Exceptions" box under "Breakpoints" on the leftenter image description here

Sludge
  • 6,072
  • 5
  • 31
  • 43