An ordinary VB developer shares his own successes and failures
"On Error Resume Next" considered harmful
Discusses some unexpected implications of using the 'On Error Resume Next' statement in Visual Basic applications.
As any seasoned VB programmer knows, theOn 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 SubIf 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.
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 goThis 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 SubThe 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".
© Palo Mraz - June 8, 2003