The best way to take care of program errors is to prevent them from occurring in the first place. Easier said than done, of course, but there are some simple things you can do that will decrease the likelihood of a serious coding error

The first and most important thing you can do to prevent errors is to design you program thoroughly before you write a single line of code. Many errors occur simply because not enough thought was given to how the program will work and how it will react to unusual situations. For example, a program that accepts some form of input from the users might not take proper precautions to ensure that the data entered is valid. The program might crash when an unexpected data value is encountered. The culprit behind the error is not poor coding but poor planning. If more attention had been paid durning the program's design phase, it's likely that the potential of such a situation occuring would have been realized. The code would reflect this by trapping for such a situation.

Of course, there are times when even the most diligent design and planning efforts leave some circumstance unaccounted for, causing an error to pop up unexpectedly. It happens to everyone from time to time; no one is perfect. But proper design tenets should be followed to keep such errors at a minimum.

Object-oriented programming techniques lend themselves to the prevention of errors. OOP makes it possible to write and thoroughly test code once and then reuse it again and again. Without having to "reinvent the wheel", the likelihood of erros occurring in reusable objects is reduced. OOP also enabled you to create a class or utility object that handles errors. This componet can then be used in any project, resulting in a consistent method of error handling.

I'll post some more information on this subject in a few hours.

Here is part two.

In the old days of BASIC programming, lines of code were prefixed with numbers. Error messages would specify the number of the line of code that generated the error, so debugging was somewhat simplified. Unfortunately, Visual Basic is not nearly as specific when reporting errors. When an error does occur in a VB program, little information is provided as to its source of even which module it occurred. To make things worse, error messagers are often cryptic. The same error message may signify a variety of problems, leaving the programmer(you) with only a vague idea of what the actual problem might be.

The fact that VB offers little in the way of error reporting makes the implementation of error trapping alll the more important. By adding even a simple error trapping code to all the routines in your programs, you can greatly enhance the information produced when an error occurs. You can also use the error trapper to take care of any last-minute chores that need to be completed before the program ends. For example, you might want to save any data that the user has entered. Errors are never easy to teake, but they're even worse when their effect is a loss in productivity.

When creating an error handling routine, try to design it in a way that will facilitate debugging efforts. Display as much information as possible as to where the error occurred. such as a name of the sub or function. A thing like that can cut down on your debugging time.

i'm sure you merely forgot to give reference to where you copied that. modify and give credit to the author.

If you couldn't guess, the last post was about Error Handling, this next entry is about Avoiding Program Errors. Please post some comments or suggestions.

Some of the most common program errors can be avoided by simply adding a few lines of code to your program modules. The Option Explicit and Option Base statements are two easy additions to your program code that might help you find errors.

The Option Explicit is used at module level and ensures that you do not use variables that have not been specifically declared. How many times have you mistyped the name of a variable somewhere in your code, resulting in a runtime error or, more often, a hard-to-find logic error? Under normal circumstances, Visual Basic assumes that any undelcared variable names are of the Variant type. So if you define the variable intCounter as an Integer but mistype the variable name in your code as intCountner, Visual Basic will mistakenly assume that intCountner is a new Variant variable.

Adding an Option Explicit statement is useful for preventing errors pertaining to array variables. By default, arrays in Visual Basic are zero-based, meaning that their first (base) element is number 0. So if you define a string array as strItems(25), the individual elements are numbered from 0 to 24. Being Humans, we don't naturally tend to think that way.
Instead, we think strItems(25) as being an array of items from 1 to 25. Experienced programmers are more likely to remeber that arrays are zero based by default and compensate for that fact in their code. But even experienced programmers slip up once in a while and assume that an array is one-based instead of zero based.

Adding an option Base 1 statement to your code changes the default for declared arrays from zero-based to the more natural one-based. If you find yourself consistently falling into the zero-based array trap, the use Option Base to change VB's default array attitude.

Perhaps a review of the Option Explicit and Option Base statements is elementary, but they are important tools in thwarting errors and improving the code's readability. Of course, they can't catch every error, it's not that simple ;). In many cases, a solid understanding of debugging techniques is necessary for tracking down errors.


I will talk about what you need to know about Debugging programs in Visual basic in the next post.

Of course ;), it's from my Visual Basic book. You don;t expect me to know all of this do you, lol. ;)

IF you must know what book it is from, it's by Sams - Visual Basic 6 Unleased - Professional Reference Edition(ISBN:0-672-31508-4) LCCCN: 98-89561
and it was printed in the United States of America


heh happy grok ;)

[quote author=MrRaza link=board=5;threadid=824;start=0#msg6451 date=1048713600]
You don;t expect me to know all of this do you, lol. ;)[/quote]Umm.. One would hope that you know what you're preaching...

i was joking for the most part. I use alot of the techniques i just stated. I dunno if I want to type out how to actually use Watches and break points because no one really seems interested.

I think any serious programmer will already know most of that to some extent, and any non-serious programmer has already been chased away from this forum with pointy sticks :-/

[quote author=iago link=board=5;threadid=824;start=0#msg6498 date=1048781995]
I think any serious programmer will already know most of that to some extent, and any non-serious programmer has already been chased away from this forum with pointy sticks :-/
[/quote]

Ahem...that's "point-ed sticks."

Why can't a stick be pointy?

[quote author=iago link=board=5;threadid=824;start=0#msg6512 date=1048801921]
Why can't a stick by pointy?
[/quote]

Don't you mean be?

iago, you're hurting my eyes :P

and by the way, look forward to a lecture from Kp about spelling. ;D

[quote author=St0rm.iD link=board=5;threadid=824;start=0#msg6523 date=1048811220]
[quote author=iago link=board=5;threadid=824;start=0#msg6512 date=1048801921]
Why can't a stick be pointy?
[/quote]

Don't you mean be?
[/quote]

Lies! It looks fine to me!

[quote author=St0rm.iD link=board=5;threadid=824;start=0#msg6523 date=1048811220]
[quote author=iago link=board=5;threadid=824;start=0#msg6512 date=1048801921]
Why can't a stick by pointy?
[/quote]

Don't you mean be?
[/quote]

[quote]« Last Edit: Today at 08:41:38pm by iago »[/quote]

It still looks fine, and that's all that matters :P