Provide an `onError` handler that will crash the app

[tvolkert]

The default onError handler dumps the error to the console. On release builds, it's very likely that an uncaught exception leaves the app in an unusable/unpredictable state. In such cases, it's common for the app developer to prefer that the app crashes rather than it continue in such a state. Crashing the app also triggers existing flows like built-in crash reporting.

The developer can currently stop the app by calling exit([int code]) from dart:io, but doing so looks like a "clean exit" to the OS, even if a non-zero exit code was used. Rather, we want to trigger an exit that the OS will detect as a crash, with associated error data.

I suggest we add support for an onError handler that will crash the app in such a way as to tie the uncaught Dart exception to the crash.

I see two possible ways to accomplish this:

1. Via a CrashOnDartExceptionPlugin that would set onError to a handler that forwards the exception to the OEM code via our message passing bus, at which point the OEM code would crash the app.
2. We provide a crash([FlutterErrorDetails details]) method that app developers could set as the onError handler. The implementation would probably use the same mechanics as option 1, but using built-in SystemChannels.X.

I think option 2 is probably the way to go.

@Hixie

[eseidelGoogle]

CC @yjbanov who built an app which knew how to crash various ways.

[yjbanov]

One issue with FlutterError.onError is that it does not catch all Dart exceptions, but only those that happen while the Flutter framework is currently somewhere in the call stack, such as a build() function or an onPressed callback. It does not catch exceptions that happen outside the framework. Here are a few examples:

main() {
  if (random % 2 == 0) {
    throw 'random error';  // WILL NOT be caught by FlutterError
  }
  runApp(new MyApp());
}

class MyApp extends StatelessWidget {
  build(_) {
    if (random % 2 == 0) {
      throw 'random error';  // WILL be caught by FlutterError
    }
    
    return new FlatButton(
      child: Text('Crash'),
      onPressed: () async {
        // WILL NOT be caught by FlutterError because it
        // runs asynchronously, not while the framework is
        // processing the gesture.
        await callPluginThatCrashes();
      }
    );
  }
}

The solution is to capture errors both in FlutterError.onError and in a zone created specifically for the app, such as:

main() {
  FlutterError.onError = (errorDetails) {
    // errors caught by framework
  };

  runZoned(() {
    if (random % 2 == 0) {
      throw 'random error';  // WILL NOT be caught by FlutterError
    }
    runApp(new MyApp());
  }, onError: (error, stack) {
    // errors caught outside the framework
  });
}

A second issue is that our runtime semantics are similar to that of a web browser - keep on truckin'. If we let errors fall through, the engine will catch it and just print to STDERR. So yes, if you want to crash then you do need some way to tell the application to crash explicitly.

My intuition is, because we see Flutter as a view embedded in a native app, so should uncaught errors be exposed to the native code via FlutterView and/or FlutterActivity. Then a developer could decide what to do with them.

Strawman for Android:

FlutterView view = ...;
view.addErrorListener(new FlutterErrorListener() {
  void captureError(FlutterErrorDetails details) {
    // do whatever is necessary, log, crash, recover, etc.
  }
});

Something very similar would be provided for iOS.

[yjbanov]

Also, I think in release builds the default FlutterError.onError behavior should be to let the error propagate to the root zone, so that there's no need to register multiple last-resort handlers.

[yjbanov]

Oh yeah, the crashy app is here: https://github.com/yjbanov/crashy/blob/master/lib/main.dart

[tvolkert]

See also: #10695

[Hixie]

FWIW, on iOS, dart:io's exit() will cause the app to appear to crash. There's no "intentional quit" on iOS.

As @yjbanov says, FlutterError.onError is specifically about errors that the framework itself caught while running. There's actually a wide range of those errors that are somewhat benign and won't cause the app to be unusable. I'm generally interested in making the framework more resilient so that more cases are benign (in terms of the app still running). I haven't particularly spent any effort doing that so far.

[tvolkert]

Side-note: right now uncaught exceptions get swallowed and don't even show up in the logs on iOS (#11238).

I do think it'd be valuable to provide a way to apps to hook into uncaught exception handling. Then if they want to make all exceptions uncaught (and thus flow through their custom handling), they should be able to do the following:

FlutterError.onError = (FlutterErrorDetails details) {
  if (!details.silent) {
    // it'd be nice to be able to rethrow here and preserve the stack trace...
    throw details.exception;
  }
};

[tvolkert]

Another option that @yjbanov was musing about was having uncaught exceptions forward back to FlutterError.onError...

https://fuchsia.googlesource.com/tonic/+/master/logging/dart_invoke.cc

[Hixie]

Closing as dupe of #614.