Introductory Program Elements

Keywords in Visual Basic are case sensitive, sort of. Visual Basic keywords do indeed have a specific case, where some letters in keywords are upper case and some are lower. The difference with VB is that the VB compiler does not complain if you enter the case incorrectly. Quite the contrary, it just fixes it for you. The end result is that the developer does not have to worry about the case sensitivity.

1. to provide documentation for you, or more importantly, for someone else in the future.

2. to aid in the use of manual debugging statements; after the debugging is complete, these statements can simply be commented out, should (i.e. when) more debugging be necessary.

3. to remove sections of potentially suspect or damaging code, then verifying this was the code causing the problem. If this code was not the problem, it can simply be uncommented.

Visual Basic uses the single quote character (') to begin the start of a comment line. This character can go anywhere on a line, but everything following the quote character (to the end of the line) is a comment. Note also that comments in VB do not need an end comment character, they are terminated by the end of the line (e.g. EOL).

Comments in VB are single-line comments (also called in-line comments). While some languages allow for comment blocks, VB does not. However, multi-line comments in VB can be formed by several single line comment lines. Some examples of comments may look like the following (note, comments in VB usually appear as green text):

	decTotal = decSum * conTaxRate		 ' add in sales tax


	'************************************************************
	'*
	'*  Code to format output follows
	'* 
	'************************************************************

If we look at programming errors in the context of when they happen (or at least appear) as well as the reason(s) behind why they happen, we can summarize as follows:

1. compile-time errors (also called syntax errors)
   • when: at compile time, i.e. caught by VB compiler (note these can happen in design mode (as interpreted) or during the compilation of the program)
   • why: violations of VB keyword syntax, e.g. typos, missing end symbols, argument or type mismatch, etc.

2. run-time errors
   • when: during program execution
   • why: mathematical errors, e.g. division by 0, invalid user input, resource issues such as files not found

3. logic
   • when: during program execution, but really occur during the design phase
   • why: faulty design, incomplete design, poor planning, insufficient testing

Students often ask what is the easiest (least difficult) or hardest (most difficult) type of error to find or fix. The answer to is this is somewhat straight forward. The easiest type of error to diagnose is a compile-time (syntax) error, due to the fact that VB quite nicely identifies these for you. When syntax errors occur, VB will identify these with blue squiggly underlined text. VB is quite good in diagnosing syntax errors such that the squiggly line will appear under the text where VB thinks the problem is located. The squiggly line will usually appear as the incorrect syntax is keyed in, but not always. Examine the code example below and see if you can identify the problem:

In addition, VB will also show a list of error information in the "Error List" window if and when a syntax error is recognized. This will usually contain really accurate, useful information regarding the error, such as what might be the cause, line number where the error occurs, etc. Clicking on the error description will even take to you the erroneous line of code. Examine the Error List from the above error:

It is paramount that you carefully read the diagnostic message(s) generated by the syntax error; this will indicate the cause of the error and potentially how to fix it. Keep in mind that if you have syntax errors, you cannot successfully compile your program without successfully correcting them.

The next error type to discuss are run-time errors. As mentioned, these errors occur during the execution of your program, and are often due to invalid user input. Examine the run-time error in the diagram below:

As should be apparent, this program abnormally terminated (i.e. crashed) due to a division by zero situation. More often than not, continuing from an unhandled exception will not produce successful results. The way to prevent run-time errors is to handle or trap potential invalid input so the error will not occur. In this situation, if the interest rate value of zero was identified and the user notified, a warning could be issued and the unhandled exception avoided. More on this in the section on data validation.

The final error type and the most difficult to identify is the logic error. Examine the program displayed below:

There are no warnings of unfortunate behavior, unhandled exceptions or any indication of programming gone bad. Notice, however the calculated value in the Monthly Payment text box. Doing some quick arithmetic (in our heads) we can approximate that 10 months would generate 35,970 dollars; thus in three years, we would surpass our initial loan amount, a far shorter time period than our 30 year selection. To all, this should be an obvious error.

Next Section: Intro to Variables

Table of Contents

©2007, Mark A. Thomas. All Rights Reserved.