Keep calm, log and crash!

Crashes happen and will continue happening. And with the years, I have grown to appreciate the value of letting the app crash, and do it as soon as possible rather than trying to move forward at all cost hoping the issue goes away.

There are two aspects associated with your app crashing. One is the obvious for us engineers, how to track the bug and fix it as quickly as we can. But there is another aspect, not always obvious, is the user experience. Ever seen this dialog?

Ever seen any major app like Facebook, Whatsapp, Twitter, etc. crashing like this? rarely right? but I can tell you that those apps crash too, but they do utmost to improve the UX even when crashing.

In Android, we can approach both aspects at once, logging all necessary information we need to help us debugging the crash, and improving the user experience.

One thing is a must though, you must always have some sort of crash reporting, that gives you enough — or as much — information to tackle and fix the underlying issue. When you have that in place, letting the app crash as soon as possible, is actually a good thing. Because the reporting associated to the crash will be most accurate and will help you better understand the problem and, because trying to continue in an unknown state is a recipe for a very bad user experience.

There are a number of crash reporting tools that help you great deal with having out-of-the-box useful crash reports, and their integration is normally fairly straight forward.
These tools normally use the same mechanism to log the crashes, they register a default uncaught exception handler.

Android ships already with a default exception handler, that does something like the pseudo-code bellow.

Any crash reporting tool can register its own default handler, and normally what they do is the following.

It is good practice to call through the prior default exception handler. This way you can chain different handlers without interfering with them.

Let us say that your app uses Crashlytics, and you want to log extra information about the crash, such that user name, user id, etc.

You could write your own handler like the following.

Great! you will now get much more useful information about the crash in your crashlytics dashboard, and believe me, the right information will give super powers to debug the bug.

Your user experience hasn’t change tough. The user will still see that crash dialog, as you are calling the priorExceptionHandler, in this case the crashlytics default handler, that in turn will subsequently call the prior default handler — probably the Android default handler, that will show the dialog.

Look at the code bellow and see how this might be overcome.

Look at lines L7-L10.

  Thread.setDefaultUncaughtExceptionHandler((t, e) -> {
      // kill process, we avoid the "app has crashed" dialog
      Runtime.getRuntime().exit(0);
  });

Those lines effectively stop the chain of calls through the prior handlers and so the Android default handler will never be called and the crash dialog will not be displayed. Instead, your app will just finish giving the impression that was (unexpectedly) homed, and the user will likely re-open it.

The side effect is that Android will not log the stacktrace of the uncaught exceptions prior to Android O.

And that all there is to it. Keep calm, log, and crash ¯\_(ツ)_/¯

I you liked the article, click the 💚 below so other people will see it here on Medium.