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…
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
create procedure XXX
set nocount on
-- Procedure body goes here
grant execute on XXX to public
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
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".