This article will try to define a way of keeping error logs to 0 in you mobile app logs. Before that, let’s discuss the importance of doing this.
Error logs should be treated like crashes in mobile apps.
There shouldn’t be any error logs. Error logs shows that there is something basic not working correctly. Like crashes it should never happen. For example, the programmer is checking if there is a null and receiving a null where it shouldn’t happen. This means something is wrong and the end user is probably having a bad experience. Due to good programming there was no crash but the problem is only postponed.
The problem is that recognizing these problems without the user complaining can only be done via logs.
But if there are too many error logs, there is no way to separate the wheat from the chaff. What then happens is that nobody looks at the logs even if they have them because there are so many.
Error logs should be treated like crashes in mobile apps. There shouldn’t be any error logs. Error logs shows that there is something basic not working correctly. Like crashes it should never happen. For example, the programmer is checking if there is a null and receiving a null where it shouldn’t happen. This means something is wrong and the end user is probably having a bad experience. Due to good programming there was no crash but the problem is only postponed. Error logs should be treated like crashes in mobile apps. There shouldn’t be any error logs. Error logs shows that there is something basic not working correctly. Like crashes it should never happen. For example, the programmer is checking if there is a null and receiving a null where it shouldn’t happen. This means something is wrong and the end user is probably having a bad experience. Due to good programming there was no crash but the problem is only postponed. How to Keep Error Logs to 0
Definition of Error Log Severity
Error logs should be error events. The application can still continue to run after the error. This can be for example when I get a null pointer where I’m not supposed to get one. Or perhaps there was an error parsing the response of the server, so I got an error from the server.
Cleaning error logs
The first stage is deleting all the error logs that are not really errors.
Any log that got defined as an error but in reality isn’t an error should be removed.
The way to start is to open the logs in production and to separate out the error logs. Once you get the logs you should go over them and see first which logs happen the most. Usually a fast scroll through will show you l which logs occur many times.
Then look at the log and see what the error is.
There are a few types of traditional errors:
-
An error log that isn’t an error: For example, the error is that it can’t connect to the server because there is no internet. In this case it is wrong to have classified the log as an error. Many times mobile phones don’t have internet connection. There is nothing wrong with that. As you can see ,there can often be “error logs” that are mistakenly defined as errors.
-
An error whose source is not clear: For example, there is a log error that it couldn’t connect to the server. It could be because the internet was down, it could be because the url is wrong, or that the server is down. In such a case the programmer should add checks in the code so that only the case that it is a real error will be set as an error log.
-
A real error: Fix the error. If there is an error than it is disturbing the user experience it should be fixed.
Severity Level of API errors
In theory what I described before sounds pretty simple. The problem is that there are many situations where it isn’t completely clear if it should be an error or not.
The biggest problem is in the case of API errors.
In the case of API errors there can be several reasons:
-
There was a mistake in the client: Fix the error.
-
The server made a mistake: If you are also managing the server than this information is useful and you should fix the server so that the error won’t occur again. If you don’t manage the server than this error isn’t in your field and therefor it shouldn’t be defined as an error and you should change the log severity level.
Conclusion
By doing the clean-up described above after a time you will get less error logs and the error logs that you will have will be real bugs. This process isn’t always fast due to the fact that any change in the code must be uploaded to the app stores and only after the users use the product you’ll see a change in the log. Sometimes after a new version comes out you’ll realize that you still have many logs whose level you need to redefine. But after some time you’ll start to see the benefit of your work.
All the errors that will still be open will be real bugs and you’ll give your users a better experience.
-- Shipbook gives you the power to remotely gather, search and analyze your user mobile app logs and crashes in the cloud, on a per-user & session basis.