What Can Possibly Go Wrong?

What Can Possibly Go Wrong?

In the Throwback program, what happens if a user accidentally types a number such as 123Q? Oops. In the design environment, the just-in-time debugger pops up, and we get a nasty error message, as shown in Figure 7-1.

Figure 7-1

An error message displayed by the debugger.

What if the user accidentally types a decimal number, such as 123.45? Another System.FormatException error is generated. Now our intrepid user might type 33333333333333? Hmmm. This example illustrates another problem, as shown in Figure 7-2.

Figure 7-2

Another error message, this one concerning the size of a user-entered value.

A good rule of thumb when thinking about your programs is that if a user can enter wrong data, no matter how remote or improbable that data might be, the user will do so. Said another way, the time it takes a user to enter bad data is inversely proportional to how obscure the error that's generated is. Clearly, we must handle exceptions thrown by our program and handle them gracefully.

When working with production code, you'll find that more than 60 percent of the code is usually devoted to error handling. Including this code—attending to the details of error handling—is what separates a solid, professional program from a fragile one that can crash when something unexpected happens.

What Is an Exception?

An exception is any error condition or unexpected behavior encountered by an executing program. Exceptions can come from both a running program and the run-time environment. As a developer, you are most concerned with program exceptions that can potentially lead to a program crash. Your program might be running perfectly, but when it attempts to save a file, either the disk is unexpectedly full or the floppy drive isn't ready. An exception will be thrown in either case.

To the common language runtime (CLR), an exception is an object that inherits from the System.Exception class, the base class from which all exceptions inherit. An exception is thrown from the area of code where a problem occurs to a part of the code designed to catch and handle the error. The type of exception determines which area of code will handle the problem.

While debugging programs is an especially important topic, I've saved my discussion of the subject for this chapter because we've had so much other new information to digest. Like most everything else in Visual Basic .NET, error handling has matured to the level of implementation found in other, more sophisticated languages. But debugging starts not with the debugger but with a solid understanding of what your program does and how the user will interact with it. Writing solid code comes with time and insight. Your objective is to anticipate every possible way your program can go terribly wrong and take measures to handle those errors. The objective is to use the debugger as little as possible.

Job Interviews That Threw Unexpected Errors

There's a story about a famous computer science professor who had an opening for a junior assistant and had no end of recently minted young PhDs applying for the job. The professor interviewed a promising candidate, who was very nervous and anxious about making a good impression. During the course of the interview, the professor asked the young man how well he knew the debugger. The candidate blurted out, "I know it really well. There is nothing I don't know about it." With that the professor stood up, offered his hand, and declared the interview over. Dismayed, the candidate asked why. "Well," the professor said, "I want someone that rarely needs the debugger; it should be foreign to him." He went on to say that before anyone commits a line of code to the editor, he should have a complete understanding of how each variable will interact with the program, how it's stored in the CPU register, how it's handled in memory, and so on. If a programmer knows these things, the debugger will rarely be used, so it should be alien to the person he hires.

The professor invited the next candidate to dinner for a chat. The professor's wife brought out sizzling steaks for dinner. The candidate, while conversing, reached over for the salt and added a touch to the just delivered steak. The conversation went pleasantly for the duration of dinner, and the trio discussed everything but computer science. At the conclusion of the evening, the professor stood up and declared that the interview was over. Again, the candidate was flustered and asked why. Smiling, the professor noted that the candidate had added salt to her steak before tasting it. Well, what did that have to do with anything, the candidate inquired. The professor smiled and asked how did she know the steak needed salt before she even tasted it. "I want an assistant with no preconceived ideas." Adding salt showed him that this candidate had certain preconceptions about how things are, which was unacceptable in his research. He went on to explain that he expected his assistant to have no preconceptions because that is what keeps someone from becoming a truly great programmer. Never assume.

In our simple Throwback program, if we failed to anticipate that a user could add a nonnumeric value or add a value that exceeds the bounds of our integer data type, we would be in big trouble. Our objective is to fully understand each and every possible error, from user error to whether a file will not be present or the disk is full and we won't be able to write a value to it. This level of anticipation comes only with much practice and thinking, but if you're aware of what to look for, you can tailor your thinking to ensure that you catch most if not all errors.



Coding Techniques for Microsoft Visual Basic. NET
Coding Techniques for Microsoft Visual Basic .NET
ISBN: 0735612544
EAN: 2147483647
Year: 2002
Pages: 123
Authors: John Connell

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