A syntax error is due to a misuse of the Visual Basic language in your code. For example, the Visual Basic language has a set of keywords that you should (must) not use to name your variable. This rule is usually easy to respect if you are using a professional text editor such as the Code Editor of Microsoft Visual Basic.
The Code Editor of Microsoft Visual Basic makes it easy to be aware of syntax errors as soon as they occur:
As you can see, if you create your application in Microsoft Visual Studio, the Code Editor is fully equipped with tools to assist you to detect and correct syntax errors. If you still violate a syntax rule, when you build your project, the compiler would detect the error and point out the line, the section, and the file name where the error occurred (we will come back to this in the next lesson).
A logic error occurs when the program (the code) is written fine but the result it produces is not reliable. With a logic error, the Code Editor does not see anything wrong in the document and therefore cannot point out a problem. One of the worse types of logic errors is one that makes a computer crash sometimes, regularly, or unpredictably, while there is nothing obviously wrong in the code.
Logic errors are, or can be, difficult to spot because you will have to know for sure that the result is wrong and why (and sometimes worse, you will have to agree or accept that it is your program that is causing a problem in the computer; imagine a user reports that her computer crashes every time she starts the application you created). Because you or the user of your program would know with certainty that the result is questionable, you would have to use some means of correcting it. One of the techniques you can use is referred to as debugging.
A logic error is called a bug. Debugging is the process of examining code to look for bugs or to identify problems. Debugging is the ability to monitor the behavior of a variable, a function, or another item throughout a program. Microsoft Visual Basic provides many features to perform debugging operations.
The debugger is the program you use to debug your code. The code or application that you are debugging is called the debuggee.
Probably the most fundamental way of examining code is to read every word and every line, with your eyes, using your experience as a programmer. This can work for short code written in one file and in one class. If the code to examine covers many pages or many files, it could be aweful and tiresome to examine code with your eyes line by line. Fortunately, to assist you with this operation, Microsoft Visual Studio provides various tools and windows that you use, one window or a combination of objects. One of the tools you can use is the Standard toolbar that is equipped with various debugging buttons:
There are different ways you can launch the debugging process:
In later sections, we will see other ways of starting or proceeding with debugging. In some cases, we will see how you can suspend debugging. When this has happened, to resume debugging:
We will see other ways of continuing with debugging.
As we will see in later sections, there are various debugging approaches available in Microsoft Visual Studio. Sometimes you will want to suspend or stop debugging.
To end debugging at any time:
One of the primary pieces of information you want to get is the value that a variable is holding. A window named Locals can be used to show that value. Normally, when you start debugging, the Locals window shows automatically. During debugging, if the Locals window is hidden, to display it:
As its name indicates, the Locals window shows the values of local variables as they are changed. If there is more than one variable, the Locals window displays their names and gives a row to each variable. The Locals window organizes its information in a table or grid:
The Name column shows the name of each variable declared in the method or the section that is being debugged. If the variable is a class, a + button appears to its left, indicating that it has fields (member variables):
In this case, to show the variables, that is, to expand the node, click the + button. This would show the fields under the variable name and the name of the class between curly brackets under the Value column:
The Value columns shows the value of each variable. When debugging starts, each variable shows its default value. As debugging progresses, when a variable acquires a new value, the Locals window updates it in the Value column. In some cases, instead of the debugger changing the value, you can manually select and change it in the Locals window and press Enter.
The Type column shows the data type of the variable. If the variable is a class, the name of the class shows in the Type column.
Just as done when reading code with your eyes, the most basic way to monitor code is to execute one line at a time and see the results. To support this operation, the debugger provides what is referred to as stepping into.
To execute code one line at a time, while the file that contains it is displaying:
When code is being stepped into, the margin corresponding to the line that is being examined display a right-pointing yellow arrow:
This lets you know what line is currently considered.
When executing a program, you can specify a section or line where you want the execution to pause, for any reason you judge necessary. This approach is useful if you have checked code up to a certain point and it looked alright. If you are not sure about code starting at a certain point, this can be your starting point.
To execute code up to a certain point
A breakpoint on a line is the code where you want the exection to suspend. You must explicitly specify that line by creating a breakpoint. You can aslo create as many breakpoints as you want. You can also remove a breakpoint you don't need anymore.
To create a breakpoint, first identify the line of code where you want to add it. Then:
A breakpoint is represented by a red circular button . After creating a breakpoint, when code executes and reaches that line, it would pause and let you know by drawing a right-pointing yellow button .
After using a breakpoint, you can remove it. To delete a breakpoint:
Remember that you can create more than one breakpoint. If you have more than one breakpoint in your code, execution would pause at each one of them. At any time, you can remove one or all breakpoints. To delete all breakpoints, on the main menu, click Debug -> Delete all Breakpoints.
You can combine the Step Into feature with breakpoints. That is, you can examine each code line after line until you get to a specific line. This allows you to monitor the values of variables and see their respective values up to a critical section. To do this, first create one or more breakpoints, then proceed with Step Intos of your choice.
The Step Into feature is a good tool to monitor the behavior of variables inside a procedure. This also allows you to know if a procedure is behaving as expected. Once you have established that a procedure is alright, you may want to skip it. Instead of executing one line at a time, the debugger allows you to execute a whole procedure at a time or to execute the lines in some procedures while skipping the others. To support this, you use a feature named Step Over.
To step over a method, while debugging:
As its name suggests, the Step Over feature allows you to skip a procedure if you know it doesn't have any problem. When debugging, you choose what procedures to step into and which ones to step over.