Trapping Errors

Try as you might to be perfect, you will introduce errors into your code. Many of them will be simple typing or syntax errors that will be caught by Visual Basic. Still others will be errors of action, in which your code works differently from what you intended, that you will catch when testing your code. The remainder consists of situations that you didn't think would arise or actions you didn't think your users would take. It is for this last class of errors that error trapping is so important.

Take the following procedure, for example:

 Sub DisplayTaskNames()     Dim objTask As Task         For Each objTask In ActiveProject.Tasks         MsgBox objTask.Name     Next objTask End Sub 

It seems harmless enough because it just iterates through the tasks in the current project and displays each task name in a dialog box. But the code has a fatal flaw, assuming that there is a task on each line of the Gantt Chart, Task Sheet, or other task view. If there is a blank line, Visual Basic raises an error because there is no Task object where it expects to find one.

In this instance, there are two ways to handle the situation. The first solution is to plan for this quirk of Microsoft Project by testing for a Task object before attempting to act upon it. The If Then statement in the following code avoids the assumption:

 Sub DisplayTaskNames()     Dim objTask As Task         For Each objTask In ActiveProject.Tasks         ' When an object Is Nothing, there is no object.         ' If an object isn't Nothing, there must be         '   an object.         If Not (objTask Is Nothing) Then             MsgBox objTask.Name         End If     Next objTask End Sub 

This is an example of code being "smart." By testing for a known but only potential problem, you have effectively trapped an error before it happens.

The following code is more representative of error trapping because it uses the On Error statement and features an actual error handler, although the fact that it knows what error might occur makes it a little artificial:

 Sub DisplayTaskNames()     Dim objTask As Task         ' If an error arises, execution of the code skips     '   ahead to the label "ErrorHandler."     ' If the error is handled successfully, execution     '   returns to the line that follows the line     '   where the error occurred.     On Error GoTo ErrorHandler         For Each objTask In ActiveProject.Tasks         MsgBox objTask.Name     Next objTask     ErrorHandler:     ' Knowing that a blank line instead of a Task object results     '   in error code 91, you can clear the error and move on.     If Err.Number = 91 Then         Err.Clear         Resume Next     End If End Sub 

Cross-References  

For more information about error handling and the Err object, see the "On Error Statement" topic in Microsoft Visual Basic Help.

Error trapping doesn't necessarily mean writing error handlers that allow your code to fail gracefully, usually by telling the user about a problem and asking them to fix it. Instead, error trapping can be thought of in the larger context of "preemptive debugging." If you do a good job of planning ahead, true error handlers are sometimes unnecessary. Trapping errors can be as simple as writing code that enforces rules.

Suppose that part of your code queries the user for a number between1and 10. What if the user doesn't provide a number? Will your code fail because it expects an answer, or will it test for a blank value and re-query the user for a response? What if the user enters a letter or other invalid character, instead of a number? By thinking about the potential situation and planning ahead, you have avoided an error condition.

Tip  

Humans being human and therefore unpredictable, code that interacts with a user typically requires the most planning and error handling.

Although there is much still to learn about Visual Basic, you should now have a solid base of knowledge upon which you can further develop your skills in Microsoft Project or anywhere else that supports a Visual Basic “based language.

Cross-References  

For more information about using Visual Basic in Microsoft Project, see Chapter 31.