Determining What Happened


Handling an error is only part of the issue. So you handled all the errors and the application did not crash. So what? Handling an error only means you popped up a message box with a description of the error, but the user still cannot use the application. And most error messages are not helpful at all. How often are users getting a particular type of error? What were they doing when they got the error? How does this help the development staff? The answer is that it does not.

Some developers got smart and put the method and function names in the header of the error message. And they put some sophisticated debugging information in the message. But that requires the user to take a screenshot or report all of that debugging information to the technical support person over the phone. Users do not dislike anything more than helping you fix an application that should not have had bugs anyway. Not only are they inconvenienced by having an error, but it becomes their responsibility to help fix it.

Note

Although displaying debugging information might be considered OK within an enterprise, it is generally not a good idea. The more information attackers have about an error, the easier it is for them to exploit the error. Generally, you should hide the details about an error from the users. However, taking this approach limits the amount of information that a user can report to you about an error.

As you will see next, there is an easy, efficient way to overcome the problem of not having enough information with which to debug an error—both for an individual application and as a method that can be easily implemented throughout an enterprise.




Building Client/Server Applications with VB. NET(c) An Example-Driven Approach
Building Client/Server Applications Under VB .NET: An Example-Driven Approach
ISBN: 1590590708
EAN: 2147483647
Year: 2005
Pages: 148
Authors: Jeff Levinson

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net