Error Handling & Crash Reporting (Sentry & Crashlytics)
7 questions foundWhy is proper error handling important in a Flutter app, and what happens by default if an unhandled exception occurs somewhere within a running app?
Beginner Proper error handling ensures that when something genuinely unexpected goes wrong, such as a failed network request or an unexpected null value, your app can respond gracefully, perhaps by showing the user a friendly, understandable error message, rather than the entire app abruptly crashing or freezing, and by default, an unhandled exception occurring within a Flutter widget's build process typically causes Flutter to display a red error screen during development, while in a genuine production release build, an unhandled exception can cause the entire app to crash completely and close unexpectedly for the actual end user.
try {
final data = await fetchUserData();
displayUserProfile(data);
} catch (error) {
showFriendlyErrorMessage();
}
Real-world example A profile screen wraps its data fetching logic in a proper try catch block, gracefully displaying a friendly retry message if the request genuinely fails, rather than allowing the entire app to crash unexpectedly for the user.
Common follow-ups: What is the difference between a checked exception and an unhandled runtime error in Dart?;How does Flutter's default red screen of death behave differently in a release build compared to during development?
Dart Asynchronous Programming (Future & async/await);Unit Testing in Flutter
What is Firebase Crashlytics, and how does it automatically capture and report crashes that occur in your app once it is actually running on real users' devices?
Beginner Firebase Crashlytics is a crash reporting service that automatically captures detailed information about a crash the moment it actually occurs on a real user's device, including a full stack trace showing exactly where in your code the crash happened, along with useful contextual details such as the specific device model and operating system version, then uploads that captured crash report to the Firebase console the next time the app has an active internet connection, letting your development team see and properly prioritize real crashes that are genuinely affecting actual users out in the real world.
await FirebaseCrashlytics.instance.recordError(error, stackTrace);
Real-world example A team notices through the Firebase Crashlytics dashboard that a specific crash is affecting a surprisingly large number of users specifically on one particular older Android device model, allowing them to properly prioritize investigating and fixing that particular issue.
Common follow-ups: How does Crashlytics differentiate between a fatal crash and a non fatal caught error?;What is the typical delay between a crash actually occurring and it appearing within the Crashlytics dashboard?
Cloud Firestore & Firebase Storage;Unit Testing in Flutter
How do you properly set up Flutter's global error handling using FlutterError.onError and PlatformDispatcher.instance.onError to automatically capture every uncaught error and forward it to a crash reporting service?
Intermediate Setting up truly comprehensive global error handling means configuring two separate error handlers, FlutterError.onError specifically to capture errors that occur during Flutter's own widget building and rendering process, and PlatformDispatcher.instance.onError to specifically capture other broader uncaught asynchronous errors that occur outside of that Flutter specific widget framework itself, and forwarding both of these captured error types to a crash reporting service like Crashlytics or Sentry ensures your team genuinely captures the complete, full picture of every meaningful error actually occurring within your production app.
FlutterError.onError = (details) {
FirebaseCrashlytics.instance.recordFlutterFatalError(details);
};
PlatformDispatcher.instance.onError = (error, stack) {
FirebaseCrashlytics.instance.recordError(error, stack, fatal: true);
return true;
};
Real-world example A production app configures both FlutterError.onError and PlatformDispatcher.instance.onError during startup, ensuring that both widget rendering errors and other broader uncaught asynchronous errors are consistently captured and reported to Crashlytics.
Common follow-ups: What is the difference between a Flutter framework error and a platform dispatcher error?;Why is it recommended to set up this global error handling as early as possible during app startup?
Dart Asynchronous Programming (Future & async/await);Flutter App Security Best Practices
What is Sentry, and how does it compare to Firebase Crashlytics in terms of the additional contextual information and features it provides for diagnosing an error?
Intermediate Sentry is another popular error monitoring and crash reporting platform, generally offering a somewhat richer set of features compared to Crashlytics, including detailed breadcrumbs showing the specific sequence of actions a user actually took leading up to an error, the ability to attach genuinely custom contextual data such as which specific feature flag was active or which screen the user was viewing, session replay in some configurations, and generally more flexible search and filtering capabilities for exploring reported errors, and the right choice between Sentry and Crashlytics for a specific team often depends on their broader existing tooling ecosystem and specific feature requirements.
await Sentry.captureException(error, stackTrace: stackTrace, withScope: (scope) {
scope.setTag('screen', 'checkout');
});
Real-world example A team investigating a difficult, hard to reproduce checkout bug uses Sentry's detailed breadcrumb feature to see the exact specific sequence of screens and actions a user took immediately before the reported error actually occurred, significantly speeding up their diagnosis.
Common follow-ups: How does Sentry's pricing model generally compare to Firebase Crashlytics?;Can Sentry and Crashlytics both reasonably be used together within the exact same app?
Flutter DevTools & Debugging;Unit Testing in Flutter
Why is it valuable to log non fatal, caught errors to a crash reporting service, in addition to only tracking genuine fatal crashes that actually cause the app to fully close?
Intermediate A caught, non fatal error, meaning an error your app successfully handled gracefully without actually crashing, such as a failed network request that the user might have already retried themselves, can still genuinely indicate a real underlying problem worth investigating and fixing, and logging these kinds of non fatal errors to a crash reporting service, in addition to genuine fatal crashes, gives your team a much more complete overall picture of the various issues real users are actually experiencing, including problems that might never actually cause the app to fully crash but could still be meaningfully degrading the overall user experience in a real, measurable way.
try {
await syncUserData();
} catch (error, stackTrace) {
FirebaseCrashlytics.instance.recordError(error, stackTrace, fatal: false);
showRetryOption();
}
Real-world example A team notices through their non fatal error logs that a specific background data sync operation is silently failing for a surprisingly large percentage of their actual users, despite that failure never actually causing a genuine full app crash, prompting them to investigate and properly fix the underlying root cause.
Common follow-ups: How do you properly distinguish between fatal and non fatal errors when reviewing a crash reporting dashboard?;What is the risk of logging too many non fatal errors and how might that make genuinely serious issues harder to actually notice?
Networking with HTTP & Dio;Flutter Performance Optimization
How can custom keys, breadcrumbs, and user context attached to a crash report help a development team dramatically speed up diagnosing and reproducing a genuinely difficult, hard to reproduce production issue?
Advanced Attaching genuinely relevant custom contextual information to a crash report, such as a specific user identifier, which particular feature flags were currently active for that user, the exact specific screen they were viewing, or a detailed sequence of breadcrumbs showing their recent actions leading up to the actual error, gives a development team substantially more useful information than a bare stack trace alone, often making the difference between quickly and confidently reproducing and fixing a genuinely difficult issue versus being left simply guessing at its actual underlying root cause with very little concrete information to actually work from.
FirebaseCrashlytics.instance.setCustomKey('feature_flag_new_checkout', true);
FirebaseCrashlytics.instance.setUserIdentifier(userId);
Real-world example A team diagnosing a crash that only seems to affect a small subset of users discovers, using custom keys attached to their crash reports, that every single affected user happened to have one specific experimental feature flag enabled, immediately pointing them directly toward the actual underlying root cause.
Common follow-ups: What personal or sensitive information should generally be avoided when attaching custom context to a crash report?;How do you properly and consistently set a user identifier across both Crashlytics and Sentry simultaneously?
Flutter App Security Best Practices;State Management with Provider
How should a team establish an alerting and triage process around crash reporting data, ensuring that a sudden meaningful spike in a specific crash's frequency is actually noticed and addressed quickly after a new release?
Advanced Simply collecting crash reports alone provides limited genuine value unless a team also establishes a clear, deliberate process for actually monitoring and responding to that data, typically including configuring automated alerts that specifically trigger whenever a particular crash's frequency spikes noticeably above its normal established baseline, especially shortly after a new release, along with clear ownership and a well understood escalation process ensuring a genuinely significant new crash is investigated and addressed promptly, since a crash reporting dashboard that nobody actually regularly monitors provides only limited real, practical value to the team despite continuously collecting a large amount of underlying error data.
// Example alerting rule configuration
// Trigger alert if crash-free users rate drops below 99% within 1 hour of a new release
Real-world example A team configures an automated alert that immediately notifies their on call engineer whenever their crash free user rate drops below a defined critical threshold shortly after a new release goes out, allowing them to quickly identify and roll back a bad release before it could meaningfully affect a large percentage of their overall user base.
Common follow-ups: What is a reasonable crash free users rate target for a typical production mobile app?;How does a staged rollout combined with active crash monitoring help further reduce the overall impact of a bad release?
App Deployment (Play Store & App Store);CI/CD Pipelines for Flutter Apps