Handling Errors in Mobile Apps
We are living in a world which is shaped by humans and humans are supposed to make mistakes. Not just they do mistake they also make your machines to do mistakes.
There are many software errors, you can find many existing articles like this.
If I have to classify these errors in perspective of mobile development, i.e, in terms of Android or iOS, there are majorly two kinds of error in simple words, avoidable and unavoidable error.
Avoidable errors, these kinds of errors can be avoided by the developers if they are able to think about the cases and handle them correctly.
Unavoidable errors mostly depend on which machine code is going to run. It might occur due to low memory, OS compatibility (like some things work in most devices but not in rooted or jailbreak devices).
In this article, I am going to put forward my point of view on how to handle errors. Also, I want to share my perspective on when it is OK to crash the app as there was an ongoing debate in our organization that we should crash the app or silently handle the wrong use case. There was a case of simple parsing where one platform crashed the app and another failed silently.
Idea
We make apps for our users and they should have the best experience possible for them. Now consider the image below,
What should we do? Should we crash the app in this scenario or the above way is the correct way to handle this? Most of you must have already guessed the better way of doing this, that there must be a way to show error like ‘unable to fetch your recent searches’ or skip the section. Let’s see how to handle these errors in a simple 3 step process.
Step 1: Identifying Scenarios
This step is very simple where all of us try to find out all possible use cases where things can go wrong. Just remember one thing here that every feature you develop has its own problems and use-cases. So, giving proper time to this step is very crucial.
Step 2: Thinking fallbacks
Once you have successfully identified all the use cases, there are two ways to go, either make it a valid use case for the user like skipping the section in the above example or make it an invalid use case where the user can see the proper error which is relevant to his context as everyone wants transparency.
This point might require you to sit with the UI/UX designer or Product Manager, make them understand the use-cases you have identified and discuss on how to handle them gracefully.
Step 3: Implementing fallbacks
Now, this is an important and obvious step that once you have identified them just implement. I added this step only to make you understand that it is more important to identify invalid use cases as because of these scenarios users can uninstall the app which will increase dropoff and later drop in conversion.
A happy flow is what you suppose to do but handling unhappy flows will increase the wow factor in your app.
At this step, you must also implement logging/reporting all invalid cases in the system for later issue identification and stability. You can push these events on Fabric or any analytics tool in the organization.
Conclusion
Is there any scenario where we should crash our app? Well, there should be none but yes if it is an unavoidable error or if there is any case that is not covered by you then the app should crash. In conclusion, handle the error in such a way that it should make sense for your user. Most of us already know this but I still see some debates around me which motivated me to write this article.
As a frontend developer, we are the closest person in the hierarchy which interacts with the user which in turn brings lots of responsibility on our shoulders. It is our responsibility to provide them good hospitality even if things are not going in the right direction.
Thanks for reading!
