The Mind of an Angry Coder: I Take Exception to That Many products are taking advantage of the enhanced exception management features that the .NET Framework provides, yet very few are going the extra mile to provide instant solutions. My favorite source code repository is SourceGear's Vault [1]. Besides being written in .NET, it is highly optimized for remote development scenarios. I was installing a new instance of Vault on one of my client's servers the other day, though, and got a cryptic message about a cryptographic exception. I emailed SourceGear's support team, and they responded promptly with instructions on how to fix the issue (even on the weekend). The details of the fix aren't important. What I found a bit annoying is that the Vault tool itself did not make any suggestions on how to fix the problem. All I got was a stack dump, which I had to email to SourceGear support. I see this situation all the time. Companies effectively use the .NET Framework's exception management features to prevent their applications from crashing, yet provide only confusing exception messages to the users instead of providing suggestions to fix the problem. When I am building and testing an application, I include instructions in my exception messages to help me fix known problems when I run into them later. Some of you might be thinking, "That's what a KnowledgeBase is for," and you'd be right. It is equally important to keep accurate documentation of problem/solution scenarios in a KnowledgeBase (SourceGear's did not have my problem listed). Why make your users search through a KnowledgeBase, though, when you can provide solutions directly in the exception management code? Many users don't even bother with the KnowledgeBase and call your support team directly (which can get costly). You might be asking, "What about issues that I don't know about when I ship my product?" Good question. This is where you need to apply a little bit of ingenuity. I see two possible alternatives to solve the "unknown issue at ship time" problem. For either solution, you first need to implement a mechanism to gather metadata about each exception that occurs in your application, such as exception type, current method, calling method, and so on. You'll need a centralized exception management architecture. If you haven't already built your own, I suggest that you take a look at the Microsoft Exception Management Application Block [2]. The first way that you could effectively utilize the exception metadata that you have gathered is to borrow a page from the anti-virus software market and build a KnowlegeBase definition update process into your application that would keep the suggested solutions in your application fresh. If you don't like the thought of having to download KnowledgeBase data into your application, a second alternative is to use your exception metadata to build a hyperlink to your company's KnowlegeBase Web site. That way your user can click on the hyperlink to check if their exception has a solution, rather than sift through the KnowlegeBase themselves. Of course, you'd have to allow the user to copy the hyperlink to the clipboard in case the machine with your application on it doesn't have access to the Internet. Your goal should be to make your application as issue-free as possible, but your secondary goal should be to make life for your users as easy as possible, if/when they run into an exception. If you are building an application, then either of my suggestions would work well. If you are a component vendor, then my second suggestion is much more practical. Give it a try, and you'll be surprised at how much your support efforts and costs go down. |