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.
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".
Comments