Let’s start with something we are all familiar with, exceptions, errors and crashes. I think it’s fair to say that making your app bug, or at least crash free would be the number one priority. Not to state the obvious, but its very bad manners to have your app crash with an unhandled exception. While on the face of it, exception handling may seem binary – the app had an exception or it didn’t, this is not how it goes. I’m sure most of you are aware of the undocumented feature meme, making fun of an application’s unexpected behavior. This type of error or misbehavior is subtle, and its capture is accordingly more complex so I will tackle it after addressing crashes and exceptions.

At the very least your app should have some general exception handler to allow it to exit gracefully. While not crashing out, exiting with some generic error message isn’t much better and will leave users frustrated. Like any product, if it breaks people won’t buy it. If you are developing for an enterprise environment where staff are forced to use your app, users will bad mouth it and it will take some time to regain their trust even when the bugs are fixed. Most, as in 99.9% of users will not report a bug with any kind of useful information about what function they were performing at the time and the application state at the time, assuming that they could. In an ideal world we would have tested the app and it would be deployed bug free. As this almost never happens the next best thing, is that we, the developers are informed of these exception situations with relevant application state data so that they can be addressed and remedied as quickly as possible.

If we were going to design an error feedback, or bug tracking solution from scratch what would it look like? This solution needs to work on 2 levels. From a project perspective there needs to be a bird’s eye view of the current state, global reporting and monitoring at a glance. Enter the project dashboard. We need to easily see the number of outstanding issues, work in progress and completed tickets. What bugs those issues relate to, and where those issues are in relation to resolution. A good comprehension of the current state of play allows for effective project management in terms of directing resources to where they are most needed. Without this information any predictions in delivery times range from less than optimal to arbitrary. The other level a bug tracking solution works at is ticket level, managing and monitoring individual issues. We need to capture the bug with as much diagnostic information as possible. Then enter the bug into a workflow. This should involve an initial categorization, which at a bare minimum, should discriminate between crashes and non-fatal errors using a priority rating. Then there should be the ability to assign the bug to a development resource, with that resource updating the current status of the bug and the resolution process. Once the bug issue has been resolved or fixed, then the bug status can be set to closed.

For a start we would need to capture the exception in the application. This would involve recording the location of the exception, like the function and library, perhaps with the input parameters. Ideally you would want to know what operating system and version the app was running on, and even the device. Once the critical data has been collected it needs to be transmitted to an error log external to the application. Once the error data has been received it would be nice if it was automatically classified and prioritized. For example, an exception that caused the app to crash would be marked as critical, while a null object exception that was caught, handled and not visible to the user maybe giving a lower priority. The exception priority will influence whether a special release is urgently needed, or the fix can be incorporated into the next planned release. The fix is implemented, and the new release is deployed, closing the feedback loop.