Subscribe to Software Autopsy        RSS Feed


Icon Leave Comment
I have written these thought mainly based on debugging experience in Visual Basic and Visual Basic for Application and some thoughts are general

"Debugging is like freezing a person and cutting him/her open, find out what's wrong fixing them and unfreeze them again"..

Why does one need debugging?

If every programmer wrote perfect code in the first attempt, the world would be a better place, no jobs for testers, no one to make the programmer’s life miserable. Unfortunately, that rosy picture has not been painted yet, probably never will, so there are testers, who find bugs and programmers fix them. It is a vicious circle, same like the circle of life. Bugs are born, killed, more bugs are born, and the killing goes on. Here killing can be either fixing them permanently, until it shows up again in some other form or some other program, or temporary fixing, like the fixing that we do at our homes, put a patch, then water leaks out again, until you realize its better to get a plumber and get is fixed once for all. In programming world, a programmer is the plumber, electrician etc.

“All the errors can be attributed to human error.”

The computer is an example of a perfect slave; it does exactly what you ask it do. To communicate with the computer we need to knows it language and we do not know the language the computer understands, and the computer cannot understand the language we speak, so you need some one who can speak our language and the computer’s language as well. Let us call the person who understands both the languages as “Programming Language.” You instruct the programming language what to do and it takes these instructions and converts it into a set of instructions that the computer can understand. Computer reads those instructions and produces the output. If the output is wrong it is very much likely that you made a mistake in the instructions, or if the programming language made a mistake in converting the instructions set, so the team that made that programming language is to be blamed. Remember when you blame, blame the whole team. While giving credit make sure that the people who contributed get the due credit. Some on said somewhere “Some on screwed up somewhere”. As I mentioned a bit while that computer is a simple slave who can blindly follow the instructions. I have seen a lot of people blame the computer for the errors made by a human. A computer cannot be blamed for the mistakes made by the person that gave the instruction. To check where and which instructions were given wrongly i.e. the instructions were given in the correct format, but the rules to be followed while doing the instructions are wrong you go and dig the code for hunting the elusive errors. For example, the master tells the slave to clean the house, which is a valid instruction, but while cleaning the house he failed to mention soap water. The slave used plain water and cleaned the house, perfectly correct, but it was the master’s fault for mentioning for not mentioning soap water. Never blame the computer for mistakes, the person who screwed up is to be blamed. As of now, computer cant’ do anything on its own unless the human using it instructs it to do. So let us face the reality either you are doing the right thing the wrong way or the wrong thing the right way. There is another way you can do the wrong thing the wrong way, which is bad.
Debugging Process

Debugging sounds very glorious and yea it is in reality, but when you actually do it, it is very tedious and monotonous. Imagine going through lines of code, systematically, just to find that a very silly was made. Some mistakes are so silly that, it is worth laughing. Some mistakes are so bad enough that, it could prove fatal, embracing, or even catastrophic or whatever you want to name it (there are real life examples). Whatever the out come of the error, it is an inconvenience to the end user/customer. Therefore, when you finally deliver the software to the end user/customer, make sure that you have done proper testing, though 100% is not possible, but make sure through testing is done. It looks bad when the end user/customer point out bugs or errors in your program, but now a days due to the complex nature of the software, companies employ error reporting feature into the software, that collect the nature of the error and all the user has to do it click the ‘submit’ button. It is may be embarrassing if he/she suggests what can be done to correct them the bugs found (There is nothing to feel embraced about it, someone thought about what the programmer could not).[/i]

When and why?

Typically, a programmer writes code, (any one who writes code is programmer, and need not have the tag or title). He executes the program, and finds that the output is not correct, or it is the correct output, but the formatting is not correct, or the program after accepting input from the user appears to be doing some processing, but it is stuck there. Imagine the program quits unexpectedly just after the user clicks the save button, or just for no reason, there is a reason, but it is not obvious the program quits. Even worse, it is crashing the operating system, which is otherwise running smoothly (exception in case of Windows 98X and ME) crashing sounds so cool, it is not in reality. It is very horrifying when user has written some documents while the running your program, and has not saved the documents, and the system crashes. The OS will warn the user the program has crashed (Blue Screen of Death), just imagine the horrifying look on the user’s face when he/she realizes that it was your program the made him/her loose the data. If it is really worth, expect a lawsuit, other wise he/she will certainly curse you. On the other hand, imagine yourself, to test the software you built, you provide some input and the program crashes; and you had not saved the program thinking that it will certainly work, sounds funny? You lost all those lines of code, you had just typed. Therefore, before executing the code, save it, it saves lot of cursing. Best way to begin the process of debugging is to try to isolate the location of the bug and then debug from that point. It is a bit creative process and if done correctly, it will fetch good results. There is no need to debug the code that is working correctly; you need to debug only the lines of code that you suspect. With experience, you will certainly can isolate or narrow down the bug location with ease.

There is an exception to running the code line by line. When maintain application you want to understand what is happening in a function, what action each line of code performs. You want to see the code in action; execute line by line and observe the output of the lines, observe the values in the variables and when the variables loose scope, observe the values in the global variables, when they are being overwritten by mistake or correctly.

Typically when you are debugging a piece of code you are looking for a logical error looping errors, variable assigned wrong values, parameters passed to the functions, etc.

Debugging Pit Stop(VB or VBA)

You can use the immediate window (Press CTRL+G) and view the values of the variable by typing “?” followed by the variable for e.g. to see what the variable x contains type in the immediate window

You can also execute commands in the immediate window say for example

Msgbox range (“A5”).value
Msgbox Range(“A15”).value

In the code you can use the debug.Print to print the values in the immediate window

Break point and STOP

(Source: -

Pressing F8 causes VBA to execute each line one at a time,

If your procedure calls another procedure, pressing F8 will cause VBA to step inside that procedure and execute it line by line. You can use SHIFT+F8 to "Step Over" the procedure call. This means that the entire called procedure is executed as one line of code. This can make debugging simpler if you are confident that the problem does not lie within a called procedure.
You can use CTRL+SHIFT+F8 to "Step Out" of the current procedure. This causes VBA to execute until the end of the procedure is reached (an End Sub or Exit Sub statement) and then stop at the line of code immediately following the line which called the procedure.
Run To Cursor tells VBA to execute code until the line on which the cursor is sitting is reached. When this line is reach, VBA enters break mode. This is similar to putting a break point on a line of code, except that the break point is temporary. The second time that line of code is executed, code execution does not pause.

There is a very interesting command in VBA that allows for debugging its called STOP. When the complier comes across this command it stops executing the code.

Other technique is to a breakpoint. Breakpoints are like Red Light or stop signals of Traffic Lights. It is as if you are telling the code to stop or halt as soon as it spots the ‘Red Signal’, just as the ‘Red Signal’ is not permanent, when you close the file, the break point not save along with the file. While the stop statements are not removed when the file is save and closed.


Wachtes are verys use to observe the variables while the code is in action. You can observe variables, a range, or individual cells, or a complete sheet. Beauty of wathces is that you can stop exectuing code when the varibale changes value, or when the value becomes true, or you can just watch the values.

Adding watch is you wear a watch and see the time when you want

Quick watch is you ask some one else and know the time

Thinking on the higher level when you are debugging you are observing a symptom, and what to know what is the cause of the symptom and fix the cause. The following table makes sense to me. Each bug that shows up in the system is a symptom of something that went wrong, you have to find what is causing the bug, and what is the solution is or fix for it you have for it.

Symptom Cause Fix/Solution

Just few more things to add, propably then it should look good

0 Comments On This Entry


January 2021

24 252627282930

0 user(s) viewing

0 Guests
0 member(s)
0 anonymous member(s)

Recent Entries

Search My Blog