Section 11.3. Dealing with Logic Errors


11.3. Dealing with Logic Errors

Logic errors occur most often from conflicts between data and code. A function expects the user to enter a date in string format; the user enters his name instead. A block of code requires a number of 1 to 100; the database field somehow contains -5 instead. Invalid user data entry, unexpected results from external data sources, and good data turned bad by problematic algorithms in the code work against the applicationand against the user.

Since so many logic errors stem from issues with the data being manipulated by the application, it makes sense to focus on detecting and correcting data issues. There are two key places in any application where data error detection is most useful: (1) when the data comes into the program and (2) when the data is just about to be processed by the program. Although data comes from many different sources (users, files, Internet connections, database queries), this section discusses user-entered data.

Consider the following function, which retrieves a number from the user.

     Public Function GetSomeData(  ) As Integer         ' ----- Retrieve a number from 1 to 100 only.         Dim userEntry As Integer         userEntry = CInt(InputBox("Enter an integer from 1 to 100."))         Return userEntry     End Sub 

Visual Basic sure makes the coding of such user interaction easy. But what happens when the user enters "101" in the InputBox's text field, or "123456," or even "abc?" To protect the program against bad data, this code needs to detect the potential logic error immediately, when the data is entering the program. The GetSomeData routine can be corrected by adding some simple data confirmation code.

     Public Function GetSomeData(  ) As Integer         ' ----- Retrieve a number from 1 to 100 only.         Dim userEntry As String         Do While True             ' ----- Prompt the user for the number.             userEntry = InputBox("Enter an integer from 1 to 100.")                 ' ----- Check for valid input.                 If (IsNumeric(userEntry) = False) Or _                     (InStr(userEntry, ".") > 0) Then                 MsgBox("Entry was non-numeric or decimal. Try again.")             ElseIf (Val(userEntry) < 1) Or (Val(userEntry) > 100) Then                 MsgBox("Entry must range from 1 to 100. Try again.")             Else                 ' ----- Looks like good data.                 Return CInt(userEntry)             End If         Loop     End Function 

That takes care of the invalid data. This function could even be modified to use either structured exception handling or unstructured error handling by manually raising errors.

     Public Function GetSomeData(  ) As Integer         ' ----- Retrieve a number from 1 to 100 only.         Dim userEntry As String         On Error GoTo ErrorHandler     TryEntryAgain:         ' ----- Prompt the user for the number.         userEntry = InputBox("Enter an integer from 1 to 100.")         ' ----- Check for valid input.         If (IsNumeric(userEntry) = False) Or _                 (InStr(userEntry, ".") > 0) Then             Err.Raise(1, Nothing, _                 "Entry was non-numeric or decimal. Try again.")         ElseIf (Val(userEntry) < 1) Or (Val(userEntry) > 100) Then             Err.Raise(2, Nothing, _                 "Entry must range from 1 to 100. Try again.")         End If         ' ----- Looks like good data.         Return CInt(userEntry)         Exit Function     ErrorHandler:         ' ----- Something happened. Show the error.         MsgBox(Err.Description)         Resume TryEntryAgain     End Function 

In most cases, detecting error issues right when they occur is best. This gives the user a chance to correct the error right away, before the errant content can cause any damage. But sometimes it makes sense to postpone analysis of the incoming data for just a little while, until just before it is used. This is most often the case on a data-entry form with many input fields. Consider the data-entry form in Figure 11-1.

Figure 11-1. Form in need of data verification


This type of form generally has code to send the user-supplied data to a database record. You could monitor every data-entry field for valid data, perhaps when each field lost the input focus, and throw up a warning message if anything was out of place. But this would quickly become tiresome to the user. In forms such as this, it's better to wait until the user is finished with all data entry and then verify the data just before using itor just before storing it in the database. The OKButton button's Click event is the perfect place to confirm all data at once and only then warn the user of data conflicts and issues.

     Private Sub OKButton_Click(ByVal sender As System.Object, _             ByVal e As System.EventArgs) Handles OKButton.Click         ' ----- Confirm and save the data before closing the form.         If (VerifyData(  ) = False) Then Exit Sub         If (SaveData(  ) = False) Then Exit sub         Me.Close(  )     End Sub 

On this particular form, the VerifyData routine would check for the following data issues.

  1. All fields other than Date of Termination are required.

  2. For new records, the Employee ID must not already exist in the database.

  3. Date of Hire and Date of Termination (when supplied) must be valid dates.

  4. If Date of Termination appears, it must occur chronologically after Date of Hire.

  5. Current Salary must be a valid number and should fall within some reasonable parameters, such as not falling below some minimum salary value stored in the database.




Visual Basic 2005(c) In a Nutshell
Visual Basic 2005 in a Nutshell (In a Nutshell (OReilly))
ISBN: 059610152X
EAN: 2147483647
Year: 2004
Pages: 712

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net