Use PlatformDispatcher.onError instead of custom zone starting with Flutter 3.3

[WasserEsser]

Platform:

• Dart
• Flutter Android or iOS
• Flutter Web

Starting with Flutter 3.3, apps should now use PlatformDispatcher.onError instead of running the app in a custom zone to catch errors. I believe sentry_flutter is using a custom zone to catch errors.

Release notes: https://medium.com/flutter/whats-new-in-flutter-3-3-893c7b9af1ff#:~:text=In%20this%20release%2C%20instead%20of%20using%20a%20custom%20Zone%2C%20you%20should%20catch%20all%20errors%20and%20exceptions%20by%20setting%20the%20PlatformDispatcher.onError%20callback.
The error handling page was also updated to reflect these changes: https://docs.flutter.dev/testing/errors

[ueman]

This scenario is already supported, but probably not as well documented as the old approach. It's also not yet enabled by default.

The following approach adheres to the new guidelines:

void main() async {
 // Do not use the appRunner callback, because that wraps your code with a Zone
 await Sentry.init(
   (options) { 
      options.addIntegration(OnErrorIntegration());
   }
  );
  runApp(MainApp());
}

For some more information, see #915

[WasserEsser]

@ueman Thanks for this, the integration works but unlike mentioned in #915, my debugPrint calls do not send any breadcrumbs to the server.

[kuhnroyal]

@ueman Thanks for this, the integration works but unlike mentioned in #915, my debugPrint calls do not send any breadcrumbs to the server.

debugPrint only creates breadcrumbs, not events. The breadcrumbs will be attached to the next event that is sent to the server.

[marandaneto]

We'd need to check the PlatformDispatcher.onError availability at runtime and use it instead of the zoned guard.
Right now it's possible adding the integration manually but we can do better.

[WasserEsser]

@ueman Thanks for this, the integration works but unlike mentioned in #915, my debugPrint calls do not send any breadcrumbs to the server.

debugPrint only creates breadcrumbs, not events. The breadcrumbs will be attached to the next event that is sent to the server.

But isn't an exception an event? Shouldn't the breadcrumbs still appear?

[ueman]

Any exceptions causes an event to be sent. A call to debugPrint is not an exception, so it will not be send as an event. However, each call to debugPrint will be recorded as a breadcrumb which is attached to events which may or may not be send afterwards. debugPrint calls will also only be recorded in release builds, because there's no good way to intercept it without loosing logs in debug mode.

I'm not sure if that answers your question, but I'm also not really sure if I understand your question 😅

[WasserEsser]

I'm not sure if that answers your question, but I'm also not really sure if I understand your question 😅

This part answered it:

debugPrint calls will also only be recorded in release builds, because there's no good way to intercept it without loosing logs in debug mode.

Our debugPrints did not show up as breadcrumbs on our issues. I was wondering why they weren't being sent over along with all the other breadcrumbs because I couldn't find any documentation on this specific behavior. Now it makes sense why they didn't show up because we're trying to see them during development.

[ueman]

Testing exceptions in debug mode doesn't really make sense in Flutter, because unfortunately there's a lot of information stripped in release builds, especially a lot of FlutterError and UI related things. So always make sure to test exception reporting in release builds.

[Vinzent03]

Am I right that when switching to PlatformDispatcher the option enablePrintBreadcrumbs doesn't work anymore, because it needs the zone?

[ueman]

Yes.

Technically, you can use both at the same time, but that wouldn't make any sense since only the zone would receive errors.

From my experience though, recording print statements isn't really worth it. Most people use some kind of a logger anyway and you can easily integrate Sentry into it. And most libraries never print anything at all. Of course your case might be entirely different.

[Vinzent03]

Yeah, I'm using a logger, so will record the Breadcrumbs myself. Just wanted to clarify.

[marandaneto]

@WasserEsser I'd keep this open till we make the onError by default.

[denrase]

It seems that the PlatformDispatcher.onError callback is available upwards of Flutter 3.1:

sentry-dart/flutter/lib/src/integrations/on_error_integration.dart

Line 116 in d90ceb9

// This error is expected on pre 3.1 Flutter version

Using it instead as default instead of the zone should be done starting with version 3.3

We don't have a direct way to check the flutter version with which the app using sentry was compiled with:

flutter/flutter#61814

Is there another way to check for Flutter version 3.3? Maybe a method that was exposed in Flutter 3.3 which we could try (and fail) to call? Or am i interpreting this behaviour incorrectly? /cc @ueman

[ueman]

Even though that callback is available pre 3.3, there's a bug which makes it incompatible. The method signature was different between io and web making it unusable. So 3.3 is one of the earliest version where it could be used. Maybe the beta before it is also working.
See #915 (comment)

To check whether the PlatformDispatcher.onError is available use

sentry-dart/flutter/lib/src/integrations/on_error_integration.dart

Lines 112 to 129 in 7987216

	bool isOnErrorSupported(SentryFlutterOptions options) {
	try {
	onError;
	} on NoSuchMethodError {
	// This error is expected on pre 3.1 Flutter version
	return false;
	} catch (exception, stacktrace) {
	// This error is neither expected on pre 3.1 nor on >= 3.1 Flutter versions
	options.logger(
	SentryLevel.debug,
	'An unexpected exception was thrown, please create an issue at https://github.com/getsentry/sentry-dart/issues',
	exception: exception,
	stackTrace: stacktrace,
	);
	return false;
	}
	return true;
	}