Use of Goto Exit_Proc

[Tim Marshall]

From http://www.mvps.org/access/tencommandments.htm

9th item:

Thou shalt not use "SendKeys", "Smart Codes" or "GoTo" (unless the GoTo
be part of an OnError process) for these will lead you from the path of
righteousness.

What about also using it as a means of exiting a procedure?

I'm a firm believer that exit sub and exit function should not be
sprinkled about tany procedure. There should one, and only one exit point.

For example:

Function fSilly() as Boolean

'returns true if the remarks are silly

dim int1 as integer 'just to flesh out the proc

On Error Goto Err_Proc

int1 = forms!frmSIlly. txtSIllyIndicat or

if int1 = 0 then

'perform all kinds of stuff

elseif int1 = 1 then

GoTo Exit_Proc

end if

Exit_Proc:

'set database variables to nothing, etc

Exit_Sub

Err_Proc:

Select case err.number

case else

'display error message

goto exit_proc

end select

--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "What's UP, Dittoooooo?" - Ditto

[Tony Toews]

Steve Jorgensen <no****@nospam. nospam> wrote:

I used to have separate exit function/sub along with whatever closing of
variables. I began using GOTo as a means to end the procedure
prematurel y if certain conditions are not meant.

I do exactly the same thing myself.

As do I - it's called a guard clause. The code presented, however, when
restructured in a clear way, no longer has a need for a guard clause employing
Goto. My example (for example) does include a guard clause, but it uses Exit
Sub.

Agreed that there are some interesting ideas which I will certainly consider for the
future.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

[Tony Toews]

Steve Jorgensen <no****@nospam. nospam> wrote:

I used to have separate exit function/sub along with whatever closing of
variables. I began using GOTo as a means to end the procedure
prematurel y if certain conditions are not meant.

I do exactly the same thing myself.

As do I - it's called a guard clause. The code presented, however, when
restructured in a clear way, no longer has a need for a guard clause employing
Goto. My example (for example) does include a guard clause, but it uses Exit
Sub.

Agreed that there are some interesting ideas which I will certainly consider for the
future.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

[David W. Fenton]

Steve Jorgensen <no****@nospam. nospam> wrote in
news:63******** *************** *********@4ax.c om:

On Mon, 21 Feb 2005 20:53:29 GMT, "David W. Fenton"
<dX********@bw ay.net.invalid> wrote:

...

(Putting stuff after the Sig line turns out to mess up Forte Agent
because it does not quote the text in the reply).
xNews quotes nothing after the sig marker unless you select the
whole message before initiating the followup. I always assume that
people are using tools that are just as good as mine. ;)
IMO, your code is about as good as it can get. The only things I
can see that would get rid of the Goto involve adding duplication,
and adding duplication is way worse than employing a Goto.

You know, looking at it again, there aren't as many GoTo's as I
thought -- I think I was consider the Resume statements in the error
handler as GoTo's, which is kind of what they are, actually (a GoTo
that will work during an error condition). They have the same bad
effect as GoTo's, in that they multiply the number of possible paths
through the code.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

Steve Jorgensen <no****@nospam. nospam> wrote in
news:63******** *************** *********@4ax.c om:

On Mon, 21 Feb 2005 20:53:29 GMT, "David W. Fenton"
<dX********@bw ay.net.invalid> wrote:

...

(Putting stuff after the Sig line turns out to mess up Forte Agent
because it does not quote the text in the reply).
xNews quotes nothing after the sig marker unless you select the
whole message before initiating the followup. I always assume that
people are using tools that are just as good as mine. ;)
IMO, your code is about as good as it can get. The only things I
can see that would get rid of the Goto involve adding duplication,
and adding duplication is way worse than employing a Goto.

You know, looking at it again, there aren't as many GoTo's as I
thought -- I think I was consider the Resume statements in the error
handler as GoTo's, which is kind of what they are, actually (a GoTo
that will work during an error condition). They have the same bad
effect as GoTo's, in that they multiply the number of possible paths
through the code.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Trevor Best]

David W. Fenton wrote:

xNews quotes nothing after the sig marker unless you select the
whole message before initiating the followup. I always assume that
people are using tools that are just as good as mine. ;)

ISTR Agent does that as well.

--
This sig left intentionally blank

[Terry Kreft]

David,
Maybe I'm missing something but isn't your code functionally the same as

If ysnInitialize Then
If dbCurrent Is Nothing Then
Set dbCurrent = CurrentDb()
End If
Set dbLocal = dbCurrent
Else
Set dbCurrent = Nothing
End If
--
Terry Kreft
MVP Microsoft Access
"David W. Fenton" <dX********@bwa y.net.invalid> wrote in message
news:Xn******** *************** ***********@24. 168.128.86...

Steve Jorgensen <no****@nospam. nospam> wrote in
news:k7******** *************** *********@4ax.c om:

On Mon, 21 Feb 2005 12:43:18 -0330, Tim Marshall
<TI****@Purple PandaChasers.Mo ertherium> wrote:

Steve Jorgensen wrote:

The use of Goto has lead to such awful spaghetti in the past
that common wisdom has been to avoid using it - period.

Thanks teve - could I ask you to have a look at my response to
Terry Kreft in this thread and offer an opinion? I think, though,
that your check list answered my question... 8)

I could, but it will probably come down to 2 smart people who
simply disagree. The only thing I might add is to say that I make
my choices pragmatically, based on what will be easiest to read
and maintain. I use certain things like the use of GoTo as red
flags to tell me I might be on the wrong track, but with the
emphasis on "might".

I would say that, discounting "On Error GoTo ErrHandler", if you
have more than one GoTo in your subroutine, you should consider
restructuring it.

After my .sig I've appended a piece of code I use in all my
applications. Can it be restructured to omit the GoTos into the
sub-subroutines? I don't think so, but maybe I'm missing something.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Public Function dbLocal(Optiona l ysnInitialize As Boolean = True) As
DAO.Database ' 2003/02/08 DWF added comments to explain it to
myself! ' uses GoTos instead of If/Then because:
' error of dbCurrent not being Nothing but dbCurrent being closed
' would (3420) would then be jumping back into the middle of an
' If/Then statement
On Error GoTo errHandler
Dim strTest As String

If Not ysnInitialize Then GoTo closeDB

retryDB:
If dbCurrent Is Nothing Then
Set dbCurrent = CurrentDb()
End If
' now that we know the db variable is not Nothing,
' test if it's Open
strTest = dbCurrent.Name

exitRoutine:
Set dbLocal = dbCurrent
Exit Function

closeDB:
If Not (dbCurrent Is Nothing) Then
'dbCurrent.clos e
Set dbCurrent = Nothing
End If
GoTo exitRoutine

errHandler:
Select Case Err.Number
Case 3420 ' Object invalid or no longer set.
Set dbCurrent = Nothing
If ysnInitialize Then
Resume retryDB
Else
Resume closeDB
End If
Case Else
MsgBox Err.Number & ": " & Err.Description , vbExclamation, _
"Error in Global Code.dbLocal()"
Resume exitRoutine
End Select
End Function

[David W. Fenton]

"Terry Kreft" <te*********@mp s.co.uk> wrote in
news:vZ******** ************@ka roo.co.uk:

Maybe I'm missing something but isn't your code functionally the
same as

If ysnInitialize Then
If dbCurrent Is Nothing Then
Set dbCurrent = CurrentDb()
End If
Set dbLocal = dbCurrent
Else
Set dbCurrent = Nothing
End If

No, because dbCurrent can be Nothing while the db it points to is
closed. I don't know how it happens with the CurrentDB() (perhaps
the wizard problem?), but it happened to me, so I wrote the code to
avoid it. If you can come up with a simpler way to handle that
condition, then I'm all for it.

This code did, in fact, start out very simple, not unlike what you
suggest, and it only got complicated after I was using it for a long
enough time to encounter a number of errors that weren't obvious to
me at first.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Tim Marshall]

Arno R wrote:

Hi Tim,

You don't want suggestions for code-change, so skip this message... ;-)
Not at all, I appeciate any input or suggestions...
I validate field-input on the before_update event of the field,
I must say I do this too, though if my field validation involves
changing the value, I go with the after update event since I have found
a lot of difficulty manipulating the .text value.
but I also need
record-validation at the form-level.
Nowadays I *always* put all my form-level validation (fields that must have a value) in a
separate function.
If you would do the same then IMO the readability of your code would improve much.
Good idea. I suspect I sometimes pack too much into my procedures.
Another advantage: This function can be used elsewhere on your form !

Thanks I really appreciate your time, Arno.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "What's UP, Dittoooooo?" - Ditto

[Tim Marshall]

Bri wrote:

Tim,

Your code does allow for a lot of confusion and maintenance problems
down the line. Also, it can frustrate your users as they fix one problem
and try again only to get yet another new error message. Here is
something I've used that might help.

Thanks. I think perhaps the main thing to d is break up the code. I do
this sometimes and othertimes I don't. I should do it mor often.

--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "What's UP, Dittoooooo?" - Ditto

[Tim Marshall]

David W. Fenton wrote:

Don't enable the OK button until all the conditions are met. You can
then use the AfterUpdate event of all the controls that have
required values to call a function that checks all the controls
involved and then enables the OK button.

<snip>

Thanks very much David. I've done this before and should try to
remember it. I think the message I'm getting from all and sundry 8) is
to a combination of breaking up the code into sub routines and/or field
level validation.

I appreciate your time, thanks. 8)
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "What's UP, Dittoooooo?" - Ditto