As any seasoned VB programmer knows, the On Error Resume Next statement is used to check for errors the old (I might also say the C-style) way. When this statement is executed, any runtime error will be silently trapped and stored in the global Err object. We VB-ers typically use this construct to execute some "non-mission critical" code, where errors can be safely ignored. The canonical example I have seen many, many times, is the Form_Resize event handling procedure:

Private Sub Form_Resize()
    On Error Resume Next
    ' Resize the child controls on this form…
End Sub

If this procedure did not contain the On Error Resume Next statement and a runtime error would occur, the application would be terminated with a nasty error message. (You do catch runtime errors in every event handling procedure, don't you?) In cases like this, the On Error Resume Next statement is quite handy, because it means less typing and more compact code. However, there are times, when this "handiness" might be very dangerous. The true danger of the On Error Resume Next statement lies in the fact that it makes it too easy to ignore the runtime errors. I have seen several cases, when ignoring runtime errors unintentionally was a recipe for disaster.

Let me provide you with a real-life example taken from my own experience.

Imagine a customer who had been using my application for several months and was happy with it. The application has a typical (somewhat boring:-) three-tier architecture (in the old days known as the Microsoft Windows DNA):

• VB6 front end; a typical forms-based application built with several 3rd party controls (GridEX, ActiveReports and AddFlow if you must know).
• VB6 back end; a DLL component configured to run as a COM+ application implementing the application's business logic (there is also the data access code-who writes middle-tier data access layer anyway:-).
• A set of T-SQL procedures for retrieving a updating the application's SQL Server 2000 database.

One day the customer requested a new feature. After analyzing the request I realized that the request could be implemented just by enhancing one stored procedure. Great, I thought. I checked out the procedure from SourceSafe, fired up Query Analyzer, changed the procedure, debugged it and tested with the application on our test system. Everything went fine. The next day I visited the customer and deployed the stored procedure on his server. After that, I started the application, invoked the feature that used the new functionality and…the application hung!

It took me two hours until I found out the problem and was able to fix it.

Here is what happened:

When writing stored procedures I always follow this pattern:

if [XXX procedure exists]
    drop procedure XXX
go
create procedure XXX
as begin
    set nocount on
    -- Procedure body goes here
end
go
grant execute on XXX to public
go

This time, however, I forgot to put GO after the stored procedure's body, so the GRANT statement has been part of the procedure itself. When the procedure was run from my test system, my account had the permission to execute the GRANT statement. When it was run at the customer's site, the GRANT statement generated the "Grantor does not have GRANT permission" error. The weird thing was that when the procedure was called from the middle-tier code (using ADO, of course), the call to Command.Execute did not generate runtime error (it would have been trapped and logged at this time) and it produced a seemingly correct recordset. The recordset was then passed to some "non-mission" critical code that looped through all the records and there was the catch. The procedure looked like this:

Private Sub CheckRecords(ByVal dbRS As ADODB.Recordset)
    On Error Resume Next
    Do Until dbRS.EOF
        ' do something - not important here
        dbRS.MoveNext
Loop
End Sub

The real problem was that the MoveNext call generated runtime error that was ignored and the loop never made it to the EOF = True condition. That's it! You can derive many morals from this story, but for me, the most important one is "Never ever use the evil On Error Resume Next statement in your code".