By default, when there is an uncaught exception the program will show a message box with the error title and the user will be asked whether they want to continue or not.
There are several problems with this behavior:
1. The user cannot really know whether the program can continue correctly after the uncaught exception.
2. A crash report will not be sent to Google Play as the error was eventually caught internally.
3. It is inconsistent as the dialog only appears when the error happens with an activity context.
4. It was not possible to override this behavior and allow sending the error with an email for example.
Starting from B4A v5.50 it is possible to change this behavior.
If there is a sub named Application_Error in the Starter service module then the default error dialog will never appear.
Note that the starter service template includes this sub. It is recommended to include this sub in all projects.
If you return True from this sub then the OS default exceptions handler is called. The result is that the app will crash and the crash report will be sent to Google Play (if the user allows it).
This is a good and standard behavior.
If you return False then the default exceptions handler will not be called. This means that the app will continue to run.
A proper usage of this is to allow you to use alternative methods to send the crash report. For example you can use HttpUtils2 to send the StackTrace to your server and then kill the process in the JobDone event.
Notes
- Application_Error will only be called in Release mode. In Debug mode the program will print the error message in the logs and will end.
- Errors that happen when the app is started, before the Starter service is ready will not be trapped. The OS default exceptions handler will handle those errors.
- The starter service must be running for this sub to be raised. It will be running unless you explicitly stop it.
An example of catching the recent logs and sending them with an intent is attached.
There are several problems with this behavior:
1. The user cannot really know whether the program can continue correctly after the uncaught exception.
2. A crash report will not be sent to Google Play as the error was eventually caught internally.
3. It is inconsistent as the dialog only appears when the error happens with an activity context.
4. It was not possible to override this behavior and allow sending the error with an email for example.
Starting from B4A v5.50 it is possible to change this behavior.
If there is a sub named Application_Error in the Starter service module then the default error dialog will never appear.
Note that the starter service template includes this sub. It is recommended to include this sub in all projects.
B4X:
'Return true to allow the OS default exceptions handler to handle the uncaught exception.
Sub Application_Error (Error As Exception, StackTrace As String) As Boolean
Return True
End SubIf you return True from this sub then the OS default exceptions handler is called. The result is that the app will crash and the crash report will be sent to Google Play (if the user allows it).
This is a good and standard behavior.
If you return False then the default exceptions handler will not be called. This means that the app will continue to run.
A proper usage of this is to allow you to use alternative methods to send the crash report. For example you can use HttpUtils2 to send the StackTrace to your server and then kill the process in the JobDone event.
Notes
- Application_Error will only be called in Release mode. In Debug mode the program will print the error message in the logs and will end.
- Errors that happen when the app is started, before the Starter service is ready will not be trapped. The OS default exceptions handler will handle those errors.
- The starter service must be running for this sub to be raised. It will be running unless you explicitly stop it.
An example of catching the recent logs and sending them with an intent is attached.
Attachments
Last edited: