Re: On Error Resume Next

Tech-Archive recommends: Fix windows errors by optimizing your registry

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

In article <SradnfbmjfJ2ssTfRVn-tw@xxxxxxxxxxx>, bcalvanese@xxxxxxxxxxx
says...
> 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
> ***.
>
> 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
>
>
>
.

Quantcast