Releasing your Buggy Code to the Wild

Share on facebook
Facebook
Share on google
Google+
Share on twitter
Twitter
Share on linkedin
LinkedIn

Introduction

While working on a network based editor extension I had to figure out how to go about handling any errors/crashes that may be caused by my plugin and having a way of handling it for the end user. Ideally when maintaining a product you’ll want to know when you users run into errors caused by your program and what errors were encountered so you can fix them for a future update. I’m going to go through things you should be checking off before releasing your buggy code to the wild.

Logging

You should be logging user’s actions throughout your program into some location. For me I was able to just keep a list of strings, but depending on your application you may need to store it locally on some kind of text file. Logs should also be prefaced with a time stamp and a tag that marks what file the log came from to make it easier to look up when looking through them. 

If your application calls for it, screenshots/videos are also good ways of keeping track of things. Taking a quick screenshot and saving that when you encounter something important isn’t unreasonable, or a quick video of a process works well.

Depending on your needs as well it can be important to log information about the end user’s  device as well, for example their IP/MAC address, GPU/CPU, RAM, current memory usage, screen , window dimensions, etc. Anything that can be related to your program.

Catching exceptions is also important. Whenever an error/exception is thrown your IDE will log this but how do you go about getting that exception? Simply surround your code with try { } then after add catch(Exception e) { } after the try expression, like below.

try
{
StreamWriter sw = new StreamWriter("example.txt");
StreamReader sr = new StreamReader("example.txt");
} catch (FileNotFoundException e) { Log("Could not find: example.txt, " + e.ToString()); } catch (AccessViolationException e) { Log("Access violation! " + e.ToString()); }
catch (Exception e)
{
Log(e.ToString());
}

Here we will always get an exception because you cannot write and read from the same file at the same time, you’d need to close one. Because we have catch, we will be able to access that error. Now we can add it to our logs. There are different types of Exceptions that you can catch but the Exception class is the base class all exceptions inherit from and will be a catch-all. Check MSDN for more information on exceptions.

Crash Reporting

When you catch an exception that’s especially notable and you can’t recover from, you might want to report this as a crash. It’s important to setup some kind of way to get crashes reported to you. At least save the crash locally and open up a screen telling the user how to send the crash to you. Ideally you should set up some kind of system that relays reports to you. For a recent project I worked on we set up a lambda function that takes in two strings, one the ID of the crash that is generated by the user, along with the crash report itself.

 

Crash/Error Screen

After you hit an error you likely don’t want the application to continue running, at minimum you want to take the user back to a previous screen so they can re-do whatever they were trying to do and give it another try. For me I like creating a screen that alerts the user that the app has hit an error, along with their error id which is reported to my server if they’d like to follow up directly. I put a restart button as well to give the user a quick way of getting back into the application. It works effectively and is useful for communicating to the user that this issue was recognized and something can be done to fix it.

 

Conclusion

In conclusion it’s important to include a specialized logging and crash handler for your applications before releasing them to the global market. Last thing you need is for a user to send you a message telling you that your program stopped working along with a poorly written account of what they were doing and them describing what happened, and having no way of knowing what exactly caused the issue and being unable to reproduce those results.

 

More to explore

Designing an Educational Game

A blog post covering my experience designing an educational game for 5th grade students in the US following common core standards.