I've seen here and in my reading that it's best to avoid using gotos in
code. The last program I wrote had quite a few, but after looking back
at them, they were mostly handling user input errors. I tried to cover
every possible user mistake because the macro creates a spreadsheet
used in some pretty backward places.

So my question is, are these kinds of gotos good uses? How do you know
whether it's a "good" goto or a "bad" goto? Any guidelines or
suggestions?

Thanks.

When handling user input errors you should be able to avoid GoTo
entirely. I've never had to use it for that purpose. The only GoTo
I've ever used is On Error Goto, which deals with errors thrown by VBA.

davegb wrote:
I've seen here and in my reading that it's best to avoid using gotos in
code. The last program I wrote had quite a few, but after looking back
at them, they were mostly handling user input errors. I tried to cover
every possible user mistake because the macro creates a spreadsheet
used in some pretty backward places.

So my question is, are these kinds of gotos good uses? How do you know
whether it's a "good" goto or a "bad" goto? Any guidelines or
suggestions?

Thanks.

In VBA, Gotos for error handling are largely unavoidable, VBA doesn't have a
good error catch.

As to whether it is good or bad, is it well structured even allowing for
gotos, can you follow it easily, is it well commented, could a different
design remove some. Answer those questions, and you can probably say it is
as best as can be.

--

HTH

Bob Phillips

(replace xxxx in the email address with gmail if mailing direct)

"davegb" wrote in message
ups.com...
I've seen here and in my reading that it's best to avoid using gotos in
code. The last program I wrote had quite a few, but after looking back
at them, they were mostly handling user input errors. I tried to cover
every possible user mistake because the macro creates a spreadsheet
used in some pretty backward places.

So my question is, are these kinds of gotos good uses? How do you know
whether it's a "good" goto or a "bad" goto? Any guidelines or
suggestions?

Thanks.

Just to add my two cents...

I find that using goto's to branch to an exit routine acceptable, too.

I think that that kind of thing can actually make the code easier to
understand. But except for error handling and application.goto <bg, those are
the only ones I use.



application.screenupdating = false
'some other setup

if somethingiswrong then
goto ExitNow:
end if

'some other stuff

if somethingelseiswrong then
goto exitnow:
end if

'some more junk

exitnow:
application.screenupdating = true
'reset other stuff, calculation, activewindow.view...

exit sub



davegb wrote:

I've seen here and in my reading that it's best to avoid using gotos in
code. The last program I wrote had quite a few, but after looking back
at them, they were mostly handling user input errors. I tried to cover
every possible user mistake because the macro creates a spreadsheet
used in some pretty backward places.

So my question is, are these kinds of gotos good uses? How do you know
whether it's a "good" goto or a "bad" goto? Any guidelines or
suggestions?

Thanks.

--

Dave Peterson

Thanks to everybody. Quite a variety of responses. Especially from
Mark!

"When handling user input errors you should be able to avoid GoTo
entirely. I've never had to use it for that purpose. The only GoTo
I've ever used is On Error Goto, which deals with errors thrown by VBA.
"

I'd be very curious to see how you can trap user errors without using
GoTo at all, without having the same code repeated in several places.
Any tips on how to do this, Mark?

Dave Peterson wrote:
Just to add my two cents...

I find that using goto's to branch to an exit routine acceptable, too.

I think that that kind of thing can actually make the code easier to
understand. But except for error handling and application.goto <bg, those are
the only ones I use.



application.screenupdating = false
'some other setup

if somethingiswrong then
goto ExitNow:
end if

'some other stuff

if somethingelseiswrong then
goto exitnow:
end if

'some more junk

exitnow:
application.screenupdating = true
'reset other stuff, calculation, activewindow.view...

exit sub



davegb wrote:

I've seen here and in my reading that it's best to avoid using gotos in
code. The last program I wrote had quite a few, but after looking back
at them, they were mostly handling user input errors. I tried to cover
every possible user mistake because the macro creates a spreadsheet
used in some pretty backward places.

So my question is, are these kinds of gotos good uses? How do you know
whether it's a "good" goto or a "bad" goto? Any guidelines or
suggestions?

Thanks.

--

Dave Peterson

I beleive what Mark is refering to is data validation. That is taking what
the user has input and validating that it is what you expect it to be (ie. a
numeric value between x and y, or a date, or...).

I am with Mark on this. All too often I see people using the error handler
inappropriatly. The error handler is like the Bat Chute. It should only be
used in case of real emergency. It is your last line of defence to handle
thing that you can not readily anticipate.
--
HTH...

Jim Thomlinson


"davegb" wrote:

Thanks to everybody. Quite a variety of responses. Especially from
Mark!

"When handling user input errors you should be able to avoid GoTo
entirely. I've never had to use it for that purpose. The only GoTo
I've ever used is On Error Goto, which deals with errors thrown by VBA.
"

I'd be very curious to see how you can trap user errors without using
GoTo at all, without having the same code repeated in several places.
Any tips on how to do this, Mark?

Dave Peterson wrote:
Just to add my two cents...

I find that using goto's to branch to an exit routine acceptable, too.

I think that that kind of thing can actually make the code easier to
understand. But except for error handling and application.goto <bg, those are
the only ones I use.



application.screenupdating = false
'some other setup

if somethingiswrong then
goto ExitNow:
end if

'some other stuff

if somethingelseiswrong then
goto exitnow:
end if

'some more junk

exitnow:
application.screenupdating = true
'reset other stuff, calculation, activewindow.view...

exit sub



davegb wrote:

I've seen here and in my reading that it's best to avoid using gotos in
code. The last program I wrote had quite a few, but after looking back
at them, they were mostly handling user input errors. I tried to cover
every possible user mistake because the macro creates a spreadsheet
used in some pretty backward places.

So my question is, are these kinds of gotos good uses? How do you know
whether it's a "good" goto or a "bad" goto? Any guidelines or
suggestions?

Thanks.

--

Dave Peterson

Don't fully agree with that Jim. It can be useful for instance to test for
the existence of a workbook, worksheet, or whatever, and take appropriate
action. Not an emergency, let alone a real one.

Bob

"Jim Thomlinson" wrote in message
...
I beleive what Mark is refering to is data validation. That is taking what
the user has input and validating that it is what you expect it to be (ie.
a
numeric value between x and y, or a date, or...).

I am with Mark on this. All too often I see people using the error handler
inappropriatly. The error handler is like the Bat Chute. It should only be
used in case of real emergency. It is your last line of defence to handle
thing that you can not readily anticipate.
--
HTH...

Jim Thomlinson


"davegb" wrote:

Thanks to everybody. Quite a variety of responses. Especially from
Mark!

"When handling user input errors you should be able to avoid GoTo
entirely. I've never had to use it for that purpose. The only GoTo
I've ever used is On Error Goto, which deals with errors thrown by VBA.
"

I'd be very curious to see how you can trap user errors without using
GoTo at all, without having the same code repeated in several places.
Any tips on how to do this, Mark?

Dave Peterson wrote:
Just to add my two cents...

I find that using goto's to branch to an exit routine acceptable, too.

I think that that kind of thing can actually make the code easier to
understand. But except for error handling and application.goto <bg,
those are
the only ones I use.



application.screenupdating = false
'some other setup

if somethingiswrong then
goto ExitNow:
end if

'some other stuff

if somethingelseiswrong then
goto exitnow:
end if

'some more junk

exitnow:
application.screenupdating = true
'reset other stuff, calculation, activewindow.view...

exit sub



davegb wrote:

I've seen here and in my reading that it's best to avoid using gotos
in
code. The last program I wrote had quite a few, but after looking
back
at them, they were mostly handling user input errors. I tried to
cover
every possible user mistake because the macro creates a spreadsheet
used in some pretty backward places.

So my question is, are these kinds of gotos good uses? How do you
know
whether it's a "good" goto or a "bad" goto? Any guidelines or
suggestions?

Thanks.

--

Dave Peterson

There are exceptions to every rule. I use that myself quite often. But in
general I see a lot of overuse of the error handler. Instead of writing a
validation routine or proper well structured code the coder just lets the
error handler pick up the problem. IMO that is a bad use of the error
handler. The error handler is a poor substitue for solid code. Error's have a
fair bit of overhead and once in the error handler any subsequent errors will
cause a real problem.

The error handler is a very powerful tool and with great power comes great
responsibility. If you over use the error handler it will come back to haunt
you at some point. Before you head into an error handler ask yourself if
there is a better way. Sometimes the anwer is no.

All of this being said EVERY sub or function that I write for production
purposes has an error handler built in. No matter how good your code is
something can always go wrong... The error handler allows you to exit from
the error gracefully and reset your system settings (if required)...

It is the same with global variables and variants and volatile functions and
.... They are very handy and very powerful. So long as the power is used
effectively and judisciously then more power to you...

--
HTH...

Jim Thomlinson


"Bob Phillips" wrote:

Don't fully agree with that Jim. It can be useful for instance to test for
the existence of a workbook, worksheet, or whatever, and take appropriate
action. Not an emergency, let alone a real one.

Bob

"Jim Thomlinson" wrote in message
...
I beleive what Mark is refering to is data validation. That is taking what
the user has input and validating that it is what you expect it to be (ie.
a
numeric value between x and y, or a date, or...).

I am with Mark on this. All too often I see people using the error handler
inappropriatly. The error handler is like the Bat Chute. It should only be
used in case of real emergency. It is your last line of defence to handle
thing that you can not readily anticipate.
--
HTH...

Jim Thomlinson


"davegb" wrote:

Thanks to everybody. Quite a variety of responses. Especially from
Mark!

"When handling user input errors you should be able to avoid GoTo
entirely. I've never had to use it for that purpose. The only GoTo
I've ever used is On Error Goto, which deals with errors thrown by VBA.
"

I'd be very curious to see how you can trap user errors without using
GoTo at all, without having the same code repeated in several places.
Any tips on how to do this, Mark?

Dave Peterson wrote:
Just to add my two cents...

I find that using goto's to branch to an exit routine acceptable, too.

I think that that kind of thing can actually make the code easier to
understand. But except for error handling and application.goto <bg,
those are
the only ones I use.



application.screenupdating = false
'some other setup

if somethingiswrong then
goto ExitNow:
end if

'some other stuff

if somethingelseiswrong then
goto exitnow:
end if

'some more junk

exitnow:
application.screenupdating = true
'reset other stuff, calculation, activewindow.view...

exit sub



davegb wrote:

I've seen here and in my reading that it's best to avoid using gotos
in
code. The last program I wrote had quite a few, but after looking
back
at them, they were mostly handling user input errors. I tried to
cover
every possible user mistake because the macro creates a spreadsheet
used in some pretty backward places.

So my question is, are these kinds of gotos good uses? How do you
know
whether it's a "good" goto or a "bad" goto? Any guidelines or
suggestions?

Thanks.

--

Dave Peterson