Error reporting in action

The other day I was trying to load notes from my iPhone to my PC when an error happened. The application I was using then sent a full error report of what happened automatically to its software developers via a dialog box with the red {sa} logo. I gave it a grin of familiar recognition, because the software developers of that application were using a Red-Gate product, SmartAssembly.

Although I was curiously pleased despite the software having crashed, I wasn’t surprised at all, because an increasing number of software companies are discovering a feature in SmartAssembly that can speed up the development process and make beta-testing software a much more painless process for both the users and the developers of the software.

We use this feature ourselves with .NET Reflector 6. When an error such as an unhandled exception happens, the user sees this dialog box …

If they click on “Send Error Report”, the developers at Red-Gate get a full description of the error and its cause, and can fix any problem very rapidly.

Any developer will prefer this to a standard stack trace, and is much more likely to be able to fix the problem quickly.

There are several more examples of such reports here….

If you are developing an application, you can add the luxury of this level of error reporting just by clicking one checkbox in SmartAssembly. It adds some clever code to your assembly to capture local variables every time an exception is thrown, and to ask your user to report it to you, with a variety of other useful information.

If you want more than this, you can also add code to attach whatever other information you want to put in your reports: you can attach your own log file or more data from the user. Sometimes just a brief description of what the user was doing can help the developer enormously to track down the problem.

It is not just the .NET Reflector team at Red-Gate that uses it. To get a developer’s eye-view of the benefits of using this system, we asked Stephanie Herrr and David Simner, who were part of the team that developed SQL Source control, what they felt about using SmartAssembly to report exceptions back to the developers.

Simple-Talk:

“What is SmartAssembly, and why was it that you found it so useful for the Beta testing of SQL Source Control?”

David:

“SmartAssembly is our own obfuscator. As well as obfuscating the code, it also adds in exception reporting, so if any error occurs, whether it is a bug in the software or a usability problem such as where the user sees an error message and doesn’t understand what it means, they can click a button and it will open up the reporting dialog. Originally, it just let the users send the report in, now it asks them optionally to provide a short description, just to help us to work out what was going wrong.

They can, if they wish, also provide an e-mail address so if we need any more information we can get in touch with them. We can also tell them if there is a workaround, what it is, and when it is fixed. If the user is willing to help us, we can request them to try out the fixed version and tell us if it’s sorted out the problem for them.

SmartAssembly is therefore really useful to us for getting error reports in from customers with very little effort from the customer apart from pressing a few buttons, allowing us to fix the issues that people are hitting and to turn the bug-fixing cycle around much quicker.

Simple-Talk:

I suppose it is much quicker for the participant because he doesn’t have to fill in a lot of details: It’s all done automatically?

David:

Yes, it automatically sends back all sorts of details. It’s particularly useful for users that are on different time zones to us, because if you’re having an endless e-mail exchange to try to work out what’s going on, it doesn’t really work very well if work-hours don’t coincide. One of the users I was helping today is in New Zealand on 12 hours ahead of us, so it’s very difficult to interact, and you have to write really precise e-mails with a great deal of information simply because, without SmartAssembly, you have to cover all the cases. Now, the detailed reports come in and are really easy to deal with.

Simple-Talk:

Magic.

Stephanie:

They have the log attached to it and we’re using our Red Gate standard logging for issues. That means that we’re logging a lot of information already. If we get a bug-report that we can’t figure out, we can add logging. The user will update to the new release in, say, two weeks time: If they hit the bug again we’ll have more details about exactly what was going on.

Simple-Talk:

Have you hit any issues about company policy on sending information through the firewall?

David:

When you click on the ‘I want to submit this error report’ button, it will attempt to reach the Red Gate web server to send the report automatically. If this fails for any reason, there is a ‘save to file’ option that allows you to e-mail the report to us instead. Yes, we’ve had the occasional user hit this problem, but the vast majority of our users are really helpful at letting us improve SQL Source Control. Our experience has been that this isn’t a common problem.

With this level of error-reporting becoming best-practice with the major players in the PC software industry it might seem tricky for the average development team to keep up. However, more and more small and medium sized software developers have discovered that they can use SmartAssembly to provide an equally slick service as the software giants, rather than spend a lot of time devising their own solution. If you choose the latter approach, how do you report the errors when it goes wrong?