Subroutine vs GOTO "On Error"

[Damian Carrillo]

This may have been covered previously, but I've not been able to find it on
the boards. In school I was taught that GOTO statements were evil, bad, and
generally not nice. I later learned firsthand about the nightmare of fixing
someone else's GOTO riddled code. Even the VBA help files warn repeatedly
that GOTO use is something to be avoided.

Despite this, the only way I seem to be able to trap errors is by using the
"On Error" statement/method:

'code here
ON ERROR RESUME NEXT
'or
ON ERROR GOTO StupidBuggyCrap
'more code here followed by blocks of code called by GOTO statements
EXIT SUB
Stupidbuggycrap:
'code to trap, display and handle errors
END SUB

I have tried to create separate error subroutines that can be called from
any module in my code, but they always fail to compile, which suggests that
calls to other subroutines are not allowed when using "ON ERROR".

My question: Why is this? And is there a way around this limitation? Am I
overlooking something obvious that allows calls to code in another module to
be used? Or are bad programming habits that make code impenetrable to
outsiders a prerequisite for any error trapping efforts? Will these forced
bad coding habits force me to GOTO hell!?

Damian Carrillo


----------------
This post is a suggestion for Microsoft, and Microsoft responds to the
suggestions with the most votes. To vote for this suggestion, click the "I
Agree" button in the message pane. If you do not see the button, follow this
link to open the suggestion in the Microsoft Web-based Newsreader and then
click "I Agree" in the message pane.

http://www.microsoft.com/office/com...fbd9d5f&dg=microsoft.public.excel.programming

 

[K Dales]

I was also schooled in the principle that GOTOs are poor programming, but an
On Error Goto is a special case (exception to the rule?) - the point is that
the code cannot continue without the error handler. A Sub would return
control to the program from where it was called - in other words where the
error occurred - which would be very dangerous. An On Error Goto gives you a
way to gracefully exit your sub without bringing your app to a crashing halt
- but it is your responsibility then to make sure the error handler
"behaves." The same with On Error Resume Next which allows you to "ignore"
an error - personally I think that is even more problematic than an On Error
Goto and I avoid it as much as possible (are you REALLY sure the only error
that can occur on that line is the one you are thinking of? I mean, REALLY
REALLY sure???).

So programmers today have a special indulgence that allows them out of GOTO
hell if, and only if, they use On Error Goto in a responsible way. But if
your On Error Resume Nexts are part of what plagues the buggy buggy computer
world there is a special place in hell just for you...

 

[Jim Thomlinson]

You are absolutely correct in your assesment of Goto. But like anything else
it is important to understand exactly what it does and when it is
approporiate to use. Goto should be used with error handling and no where
else. Period. Taken to its extreme all procedures should only have one flow
of execution (top to bottom). They should only have one entrance point and
one exit point. This rule is also broken in error handling when we use exit
sub to avoid entering the error handling code at the end of a procedure. The
fact that you know this will help you to write better code. The cardinal
rules (the world according to me) are...

Always use Option Explicit
Avoid Public declarations of subs functions and variables wherever feasable
Avoid Exit Sub and End except at the end of your subs (functions)
Always use error handlers
Don't use error handler for errors you can reasonable anticipate (write code
to handle the problem)
Always document your code

 

[Bob Phillips]

Unfortunately in VBA On Error Goto is practically unavoidable to provide
decent error handling. .Net has Catch, which is a lot neater.

From my perspective, anyone who writes poorly structured, ambiguous,
spaghetti code is capable of doing that with or without Goto's. Goto's may
make it easier, but it is not the cause of the problem. You know the old
phrase, a poor workman blames his tools.

The secret is to build well,-structured code, declare your variables, add
meaningful comments, and then the odd properly used Goto will not be a
problem.

--

HTH

RP
(remove nothere from the email address if mailing direct)

This may have been covered previously, but I've not been able to find it on
the boards. In school I was taught that GOTO statements were evil, bad, and
generally not nice. I later learned firsthand about the nightmare of fixing
someone else's GOTO riddled code. Even the VBA help files warn repeatedly
that GOTO use is something to be avoided.

Despite this, the only way I seem to be able to trap errors is by using the
"On Error" statement/method:

'code here
ON ERROR RESUME NEXT
'or
ON ERROR GOTO StupidBuggyCrap
'more code here followed by blocks of code called by GOTO statements
EXIT SUB
Stupidbuggycrap:
'code to trap, display and handle errors
END SUB

I have tried to create separate error subroutines that can be called from
any module in my code, but they always fail to compile, which suggests that
calls to other subroutines are not allowed when using "ON ERROR".

My question: Why is this? And is there a way around this limitation? Am I
overlooking something obvious that allows calls to code in another module to
be used? Or are bad programming habits that make code impenetrable to
outsiders a prerequisite for any error trapping efforts? Will these forced
bad coding habits force me to GOTO hell!?

Damian Carrillo


----------------
This post is a suggestion for Microsoft, and Microsoft responds to the
suggestions with the most votes. To vote for this suggestion, click the "I
Agree" button in the message pane. If you do not see the button, follow this
link to open the suggestion in the Microsoft Web-based Newsreader and then
click "I Agree" in the message pane.

http://www.microsoft.com/office/com...fbd9d5f&dg=microsoft.public.excel.programming