Closed githubmonkey closed 1 year ago
Ok, I've been thinking about this and I think I will just remove the guardWithCrashlytics
concept. It doesn't seem to be mentioned in the Crashlytics documentation, and when I asked (https://github.com/flutter/flutter/pull/122836#issuecomment-1575510530) about how to do it, Ian suggests to "have the zone error handler call a configurable callback that you can set up from inside the zone". That seems super convoluted and I wouldn't be surprised if it leads to more runtime errors than what it prevents.
One last chance is to ask the folks who are behind the new Firebase Crashlytics documentation and/or the migration from the old one. They probably had to deal with the same conundrum. After all, they had to see the Zoned errors section in the old documentation and had to make the conscious decision to remove it.
cc @domesticmouse -- Would you please ask? You will have better access to these folks than I do. This question (how to catch errors that happen in callbacks, and how to send them to Firebase Crashlytics / Sentry) seems much larger than the game_template
sample.
FYI @puf and @nohe427
I believe that the current guidance is to use:
// Pass all uncaught asynchronous errors that aren't handled by the Flutter framework to Crashlytics
PlatformDispatcher.instance.onError = (error, stack) {
FirebaseCrashlytics.instance.recordError(error, stack, fatal: true);
return true;
};
for asynchronous errors.
This is current guidance based on this documentation and is documented here.
The old documentation is no longer current and the firebase.google.com site should be referenced for new docs.
We should likely update the game template to use PlatformDispatcher instead.
Let me know how else I can help
Ok, I've been thinking about this and I think I will just remove the
guardWithCrashlytics
concept. It doesn't seem to be mentioned in the Crashlytics documentation, and when I asked (flutter/flutter#122836 (comment)) about how to do it, Ian suggests to "have the zone error handler call a configurable callback that you can set up from inside the zone". That seems super convoluted and I wouldn't be surprised if it leads to more runtime errors than what it prevents.One last chance is to ask the folks who are behind the new Firebase Crashlytics documentation and/or the migration from the old one. They probably had to deal with the same conundrum. After all, they had to see the Zoned errors section in the old documentation and had to make the conscious decision to remove it.
cc @domesticmouse -- Would you please ask? You will have better access to these folks than I do. This question (how to catch errors that happen in callbacks, and how to send them to Firebase Crashlytics / Sentry) seems much larger than the
game_template
sample.
@filiph should we remove guardWithCrashlytics from game_template ? ca you please update the git repo
PTAL @filiph
Sorry for the delay. I'm in discussion to make this whole template significantly simpler (and instead document the complexities of adding things like Crashlytics etc.) so please allow for a few more weeks. It's quite possible this whole thing with guardWithCrashlytics
will go away soon.
I'll keep the issue open and assigned to myself, of course.
Flutter 3.10 includes a breaking change related to zone initialization. https://github.com/flutter/flutter/pull/122836
The game_template sample is using
guardWithCrashlytics()
to run callrunApp()
inside a new zone. When calling guardWithCrashlytics in main.dart, a previously instantiated crashlytics object is passed in. To obtain that object,WidgetsFlutterBinding.ensureInitialized();
is called in a different zone . This is no longer allowed.