Handling crashes in Xamarin applications

There is different ways to handle errors and crashes in applications. I have tried out many tools like for example, HockeyApp without ever becoming really satisfied with the results. Instead I decided to go custom and develop my own system. There is a few principles that I have been sticking to when developing it.

  1. The user should never experience(notice) a crash.
  2. Crashers/errors should never be kept under the radar.
  3. Crashes/errors needs to be caught as as possible.

Let’s dig deeper into these principles.

1. The user should never experience(notice) a crash.
What I mean by this is that even if crashes occur, which they will.. They should not break the application. The reason for this is that in far most cases the application will keep running fine even though a function crashes. Let’s take an analytics system for example. Let’s say that a crash happens while sending some user statistics to a service. Allowing this to crash the whole application and ruin the experience for the user wouldn’t much sense. How about an animation for a button? Nope.. There is things everywhere that might cause crashes without affecting the overall experience for the user.

2. Crashers/errors should never be kept under the radar.
The main argument against principle 1 I heard from other developers is that they are afraid that crashes will go unnoticed and cause symptomps that is hard to debug. This is where principle 2 comes into play. It’s crucial to never let an exception slip under the radar. I have noticed that some developers adds if-statements in many places to check for null and I would say that it’s is a bad practice. Let’s have a look at this example:

In this example we are asking a service for an order and if we receive the order we print information about it, but otherwise we print an error-page. What’s wrong about this example? The problem here is that we are trying to cover up for an underlaying issue; The question we should ask ourselves here is why we are receiving a null response. Probably something is wrong within the flow itself since we are trying to get an order that doesn’t exist and if we are masking this issue we will never get to ask ourself these questions and deal with the real issue. Instead we should catch the error, send the error-information to our online logging system and then, let the application continue as usual. I will show an example if this later on.

3. Crashes/errors needs to be caught as early as possible.
This principle goes along with principle 2. Again, let the error be triggered as early as possible instead of masking it. In best case scenario we would catch all errors during development and that is what I want to aid in the development of this system. That’s why I add a crucial step in my system which is to break the debugger if it’s attached when an error occurs. This will make any developer notice an error and easily find it since the debugger is attached with the callstack and all the parameters necesarry to resolve the issue.

Let’s look at the system now.
Basically I wrap all code in try/catch and in the catch method I simply send the information forward to my Crashhandler that will dig out all the information about the error using reflection and then send it to an online logging system (Loggly or Mixpanel for example).

The advantage of having our custom error-handling system like this is that we can add whatever information we want in the Log method. We can also use it for other things then catching errors. Maybe “warnings”?

Looking back at the previous example and adepting it to this system it would instead look something like this:

We could also use a hybrid-solution that would look something like this:

When loading XAML layouts in Xamarin.Forms causes an exception it usually gets masked by default. You might receive an error in the log at most but in a lot of cases the layout will simply not load but by wrapping InitializeComponent() in a try/catch statement you will instead receive a very nicely formatted error and a breaking debugger that will make your development so much smoother.

Leave a Reply

Your email address will not be published. Required fields are marked *