On Error Resume Next

[rcalvanese]

I have been reading many posts where I see "On Error Resume Next" being used
As well as "On Error GoTo 0" (which basically disables the error handeling
for the method). I was taught in school that this is a bad programming
practice and if we used it in our projects, we would have points taken off
our grade. When I began programming for a living, I noticed it was looked
down upon by every IT Manager that I have ever met. One example that I can
give is as follows:

I was working for a telemarketing company who used VB5/VB6/VBA for just
about all reporting because all cleint reporting was done in Excel. A client
report that had been being run for about 6 months was calculating
incorrectly. This calculation was used by our client to make business
decissions and had been incorrect for the 6 months that the report was being
run. I don't know all the details about the business end of it, but... Our
company wound up having to eat 2 millin dollars. The IT manager went to the
programmer who wrote the report and found that he had used On Error Resume
Next in several places in his code. Upon commenting them all out and running
the report, he was able to find the error that caused the calculation
problem.

Needles to say, the programmer was let go the next day.

This is only my oppinion based on what I have learned and experienced thus
far. To me it just sets a potential for dissaster. I have done a lot of
Excel development over the years, but not in Excel itself. I choose to
control excel automation from outside, and have developed some fairly large
systems in VB6, and .NET. But it's just a prefference of mine not having to
maintain all those proprietary macro's and having them attached to the spead
sheet.

So anyway... I see this being used pretty extensively here and would like to
hear other oppinions as to why people would use this. Sure there are
instances where you could save a few lines of code, but a programs
effeciency is not measured by how few lines of code are used. And if there
are exceptions in anything that I develop... I want to know about it.

All oppinions welcome...

Bob Calvanese

 

[Nick Hodge]

Bob

The overall tenure of your statement is correct. In general On Error Resume
Next is 'lazy' programming. It is used extensively here as most code is by
way of example or code which is only run one or does very insignificant
tasks. If this were not the case less answers would be given and people
would be a lot more wary to do so, as they would have to write full error
checking code each time.

Seldom do problems of the magnitude you set out occur, in fact most of the
time these statements purely stop the code from dropping out for trivial
errors. (Chart sheet selected instead of worksheet, etc). Granted, it could
happen the way you outline, but far more mistakes are made in functions and
linking causing that type of anomaly than would ever be the case in code.

All together, I agree, generally bad practice unless you know the outcomes
you may get

Just my £0.02

--
HTH
Nick Hodge
Microsoft MVP - Excel
Southampton, England
(e-mail address removed)

 

[rcalvanese]

Thank you Nick for your input.

I would also like to add that anyone who is not sure of the potential risk
involved here. Please... Do a little research and make up your own mind. I
can only express my oppinion here, but I would hate to see someone get in a
bad situation thinking that it was ok because they learned it on this news
group.

Bob Calvanese

 

[Tushar Mehta]

Error handlers are the most effective way to handle errors. It has
nothing to do with saving lines of code. For me, it is more a question
of writing software that is self-documented, transparent in intent, and
easy to both understand and maintain. Used correctly an error handler
does all of that!

True, rookie programmers tend to overuse error handlers and that can
indeed lead to disasters of the magnitude you referred to. However,
that has nothing to do with how the tool is used and everything to do
with how it is abused. There is nothing intrinsically wrong with error
handlers. When a developer uses one s/he assumes the responsibility to
handle errors. If subsequently s/he shirks that responsibility, it is a
people management problem. For anyone to conclude that the tool is
flawed is -- to be blunt -- dumb. Do loops can be trouble, GoTos are
frowned upon but can be great assets when used in limited circumstances.

Personally, I find the single biggest source of poor systems is bad
structural design. Too many managers, analysts, and lead programmers
force their business application into the handful of structures they are
familiar with -- the most 'advanced' data structure being an array. Not
to mention the use of global variables. {shudder}

People and organizations would be much better off if they invested in
designing better algorithms, better data structures, and better
programming methodologies and less time on mechanical rules about atomic
language constructs.

To state that error handlers lead to poor code reveals a lack of
understanding on their value to *good* system design. They are no
better or worse than, say, a do loop. Used properly they are very
powerful aids. Used indiscriminately, like any other tool, they can be
dangerous.

I write error handlers where a function might raise an error that needs
to be handled, or where I want to handle any error that might arise, or
where I want to ignore errors. All other code is outside the scope of
error handlers. In every case, the error handler *documents* my
*intent* to handle errors; further, as the developer I am telling the OS
I will handle errors -- or at *my* discretion ignore them. Obviously,
if the software then does something dumb it becomes my responsibility.
Would I have fired the programmer you mentioned in the incident you
mentioned? Only if s/he had been made aware of the dangers of
indiscriminate use of error handlers and trained in their correct use.
I would have focused my attention on the manager who failed to properly
train her/him.

You wrote you have extensive experience with VB.Net. Given the
enhancements available in it, I am surprised anyone would even question
the value of error handlers. The Try...Catch...Finally structured error
handler construct is just that -- a *structured* construct that clearly
delineates the scope of the error(s) the programmer wants to assume
responsibility for. A significant improvement over the unstructured VBA
constructs, it is a capability that a good programmer should look
forward to using.


--
Regards,

Tushar Mehta
www.tushar-mehta.com
Multi-disciplinary business expertise
+ Technology skills
= Optimal solution to your business problem
Recipient Microsoft MVP award 2000-2005