On Error Resume Next

InfoDabble > Tech Notes > Essays > On Error Resume Next
Jump to: navigation, search
True Tales from the trenches ...

By Eric Hartwell -- Saturday, March 12, 2005[1]

I was instructed to fix a problem that a "star" programmer had discovered with my code. Apparently his VBScript routine was working fine, but when he called "my" COM component's functions the database was corrupted.

Imagine my joy when I traced through his code and found this gem:

Function WorksFine(EmployeeID)
 
    On Error Resume Next
    EmployeeRecord = LoadEmployeeData(EmployeeID)
 
    On Error Resume Next
    Calculate(EmployeeRecord)
 
    On Error Resume Next
    SaveEmployeeData(EmployeeRecord)
 
    WorksFine = SUCCESS
 
End Function

Our "star" realized that sometimes one of the component calls would run into a problem and return one of its many documented status codes. For instance, the LoadEmployeeData function might report missing data in the employee record, or even a missing employee. The Calculate function might report eligibility problems or require additional input, even assuming the data was there in the first place. Even the SaveEmployeeData function could run into problems in the multiuser system.

Dealing with all these possibilities could seem like a lot of work. But, simply by using On Error Resume Next, our "star" was able to defer error checking until the end of the routine. Then, by setting WorksFine = SUCCESS, he was able to guarantee that he didn't need to check it then either.

Of course, we had never planned to do a calculation when the data hadn't been loaded, or save the results when the calculation had failed. To make things worse, sometimes the employee record had enough valid data left over from the previous transaction that the SaveEmployeeData call could actually update the database, usually trashing some unrelated employee's data.

The "star" was quite upset when I suggested putting error handling into his routine.

It turned out he had written it this way deliberately so he didn't need to write an error handler. This was how he achieved the high productivity[2] that made him a "star" programmer, and he didn't want to hurt his record by changing "finished" work.


Moral: You get what you reward.

 


  1. Edited July, 2007
  2. This same programmer "couldn't get Microsoft's XML parser to work," so he wrote his own in "less than a week."