What happens if a bug gets through the cracks?
Writing code and expecting that it will never fail is a fallacy. It’s just like driving a car and hoping the fuel won’t be exhausted. In essence, you always have to plan for the worst that might happen. There are a couple of uncertainties responsible for code failure in an application, and I’m going to go through a few of them in this article.
Errors and Exceptions
Errors and exceptions are frequently interchanged. This can be pardoned to some extent, but they’re actually different. The best way to differentiate them is to consider the context in which they’re used in a program. Nevertheless, they’re one of the most famous causes of code failure in an application.
Error vs Exception
Errors often occur in a program as a result of a programmer’s mistake when writing or using the code. Because a program cannot recover from an error, this will result in the abrupt termination of that program.
Basically, what this means is that most times, an error is under the control of a programmer, and when a code fails as a result of an error, a programmer can be responsible for this.
Programmer errors frequently take the following forms:
- Using invalid language syntax.
- Calling a function before its declaration. (This might not cause an error in JavaScript🙂).
- Accessing an Array/List item with an invalid index.
On the other hand, exceptions in a/an program or application can be thought of as unexpected events or errors that lead to the application's code failing. An exception in an application is not the programmer's fault, but the exception can be mitigated by the programmer. An application can gracefully recover from an exception, especially when it is handled effectively.
A common example of an exception is a network connection exception that occurs when an application is restricted from accessing the internet.
Flutter error handlers
By default, the Flutter framework handles uncaught errors that occur during different phases of a running app, like the build phase, layout phase, and paint phase. Errors that occur during these phases are handled by the FlutterError.onError handler.
This handler can also be overridden, as shown below:
Aside from the FlutterError.onError invocation that occurs during the build, layout, and paint phases, the ErrorWidget.builder also gets invoked when an error occurs during the build phase.
ErrorWidget.builder works by displaying an error message on screen when in debug mode and a gray background when in release mode.
With the possibility of overriding ErrorWidget.builder default behavior, you can choose to display a different error widget when errors occur during the build phase of your app.
The above code will display this error screen when an error occurs, be it in debug or release mode:
Handling other errors
By now, you would have been wondering: since the FlutterError.onError callback handles errors that pertain to the build, layout, and paint phases, what about errors that occur outside of these scopes? Well, one way around handling every other error is by creating an error zone in the root of your app using the runZonedGuarded() method.
Since the release of Flutter 3.3, handling uncaught errors can be done in a better way with the PlatformDispatcher.onError callback, eliminating the need to create an error zone in the root of your app.
In summary, the FlutterError.onError and PlatformDispatcher.onError callbacks can be used to handle any uncaught exception when building with Flutter.