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
HIS


"rcalvanese" wrote in message
...
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