Error handling topic

An Ignored Necessity

Developers are guilty of two shortcomings when writing software:
Error handling
Documentation

Happily, not only does the Flutter Framework have its own error handler, you can introduce your own custom error handler if you want. You're encouraged to handle errors in your app because they are going to happen in your app.

Contents

Error In State

Count On Errors

Use FirebaseCrashlytics

Seeing Red

Error In State

As a further extension to Flutter's State class, each StateX class has an onError() function. It comes from the mixin, StateXonErrorMixin, and if not overridden will do nothing when indeed an error occurs (see below). However, if the onError() function is implemented when the StateX object encounters an error, the function makes it possible to handle that error so that the app can recover and or fail gracefully.

mixin StateXonErrorMixin<T extends StatefulWidget> on StateX<T> {
  /// This is called within the framework.
  void onError(FlutterErrorDetails details) {}
}

Count On Errors

The example app that accompanies the Fluttery Framework package includes the traditional 'counter app.' Note, with every tap of that button, an error is purposely thrown to demonstrate the Fluttery Framework's innate error handling. Despite the error, you see the counter is still being incremented.

In the first screenshot below, the throw command explicitly causes an exception. This would otherwise cause the counter not to be incremented with no change reflected on the screen. This error, of course, is recorded in device's log files and or on the IDE's console.

However, in the second screenshot, that State object's onError() is specifically looking out for such an error. It assumes the counter failed to increment and therefore does so there in the error routine. The third screenshot below is that of the console screen on my IDE when the error occurred.

Of course, this is a very simple example from a very simple example app. However, it does reveal the basic concept involved when an error occurs in one of these State objects. Using the Fluttery Framework, each State object could be considered its own little app, and so it should have its own error handling.

If an error occurs in the State object the error will propagate back the app's error handler, but not before calling the State object's onError() function. Error handling is, therefore, more modular and implemented more efficiently. Any possible errors are anticipated and handled in the very State object where they occur. By the way, you have means of implementing a custom error handler for your app.

counter_app.dart	counter_app.dart

Use FirebaseCrashlytics

FirebaseCrashlytics is a popular realtime crash reporter. It discretely sends a report to your Firebase console when one of your apps encounters an error. You then can be more responsive to your user if and when such issues arise. Of course, the Fluttery Framework allows you to implement FirebaseCrashlytics as your app's error handler. It's a simple matter of instantiating the FirebaseCrashlytics class and assigning the appropriate handlers.

As an example, the first screenshot below depicts how you could utilize the onInitAsync() function in the App State class, and begin setting up the FirebaseCrashlytics as the app's error handler. As you see there, if the app is running in production, any occurring errors are reported to your Firebase console. In the second screenshot, that instance of the FirebaseCrashlytics object is assigned as the app's error handler as well as report any errors occurring in the very Dart isolate or run zone executing the app. The AppWidgetErrorDisplayed is merely there to demonstrate the ability to define a custom error screen when a widget fails to display. As it is, It's already the default in the Fluttery Framework. An example of it is displayed below (see Seeing Red).

app.dart

Seeing Red

As you know, typically when an error occurs while developing in Flutter and a widget fails to display, the 'Read Screen of Despair' appears. Using the Fluttery Framework, you're greeted with something a little more helpful that displays the stack trace to the developer. Further, as you see, it's a little more aesthetically pleasing as well. Of course, you're free to implement your own custom screen if you like, and assign it to the onErrorScreen() function introduced earlier.