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

[Steve Jorgensen]

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

....

I thought about your code module again, and realized that it could probably be
clarified by extracting a test for whether the database is open into its own
procedure, like the example below.

Of course, I'm a fan of using an explicit variable to hold a return value,
even if it means I have to use a Goto as a return, but using the function name
as an implicit variable, the goto could be replaced with Exit Function if you
wanted to.

== Proposed Code ==

Public Function dbLocal( _
Optional ysnInitialize As Boolean = True _
) As DAO.Database
On Error GoTo err_catch
Dim blnIsDbOpen As Boolean

blnIsDbOpen = IsDbOpen(dbCurr ent)

If ysnInitialize Then GoTo closeDB Then
If Not blnIsDbOpen Then Set dbCurrent = CurrentDb()
Else
If blnIsDbOpen Then dbCurrent.Close
Set dbCurrent = Nothing
End If

Fn_Return:
Set dbLocal = dbCurrent
Exit Function

err_catch:
MsgBox Err.Number & ": " & Err.Description , vbExclamation, _
"Error in Global Code.dbLocal()"
Resume Fn_Return

End Function

' Calling procedure is expected to handle any unexpected errors.
Public Function IsDbOpen(dbToCh eck As DAO.Database) As Boolean
Dim strNameTest As String
Dim blnResult As Boolean

blnResult = True ' Assume True unless we find out otherwise.

If dbToCheck Is Nothing Then
blnResult = False: Goto Fn_Return
End If

On Error Goto Err_Catch
strNameTest = dbToCheck.Name

Fn_Return:
IsDbOpen = blnResult

Err_Catch:
Select Case Err.Number
Case 3420 ' Object invalid or no longer set.
blnResult = False
Resume Fn_Return
Case Else
Err.Raise Err.Number, Err.Source, Err.Description ,
Err.HelpFile, Err.HelpContext
End Select

End Function
== Code from original post ==

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

[Larry Linson]

"Terry Kreft" wrote

I've been coding for 13 years in VB and
VBA and can think of only one occasion
where I have used GoTo except as part
of an error handling routine.

The example you show does not require GoTo at all.

My personal advice is; if you feel the need to use goto:
1) Try calmimg down, you are obviously
overworked and possibly a bit
emotional.
2) Have a cold shower
3) Consider the ridicule of your peers when
they see what you have done. <G>

I was one of IBM's internal advocates for structured programming, back when
it was a "new thing" (a long time ago -- a little over 30 years ago, I was
invited to be part of a team to take a rotational assignment in Europe to
promote structured programming in IBM World Trade, but I opted to take an
assignment in San Francisco instead, and do not regret having done so) and
my view was, and is, this: When one "converts" from spaghetti code to
structured, it is useful to be strict with yourself for a period of time and
allow yourself no violations; then (as Steve said) _judicious_ violations
can make your code easier to read/follow, and that is the whole reason for
structured programming -- make it easier to read/follow and, thus, avoid
mistakes.

It is just as much a violation of structure to sprinkle Exit Sub/Function
statements through the code as it is to use Go To Exit_Proc. And, of course,
the Exit_Proc may contain other code besides the Exit Sub/Function (like the
"Finally" code of "Try / Catch / Finally" that the OOP advocates think is so
much better).

And, if I understood, the only case in which either Tim or Steve proposed
using Go To was _in conjunction with error handling_. If you do not, you are
very likely to find yourself including unnneccesary layers of conditions
just to avoid GoTos in case of error and clear need to "quit right now".
Unneccesary layers of conditions will make the code harder to read/follow
and be more conducive to the introduction of errors than a few GoTos.

Larry Linson
Microsoft Access MVP

[Steve Jorgensen]

On Thu, 24 Feb 2005 17:04:24 GMT, "Larry Linson" <bo*****@localh ost.not>
wrote:

"Terry Kreft" wrote

I've been coding for 13 years in VB and
VBA and can think of only one occasion
where I have used GoTo except as part
of an error handling routine.

The example you show does not require GoTo at all.

My personal advice is; if you feel the need to use goto:
1) Try calmimg down, you are obviously
overworked and possibly a bit
emotional.
2) Have a cold shower
3) Consider the ridicule of your peers when
they see what you have done. <G>

I was one of IBM's internal advocates for structured programming, back when
it was a "new thing" (a long time ago -- a little over 30 years ago, I was
invited to be part of a team to take a rotational assignment in Europe to
promote structured programming in IBM World Trade, but I opted to take an
assignment in San Francisco instead, and do not regret having done so) and
my view was, and is, this: When one "converts" from spaghetti code to
structured, it is useful to be strict with yourself for a period of time and
allow yourself no violations; then (as Steve said) _judicious_ violations
can make your code easier to read/follow, and that is the whole reason for
structured programming -- make it easier to read/follow and, thus, avoid
mistakes.

It is just as much a violation of structure to sprinkle Exit Sub/Function
statements through the code as it is to use Go To Exit_Proc. And, of course,
the Exit_Proc may contain other code besides the Exit Sub/Function (like the
"Finally" code of "Try / Catch / Finally" that the OOP advocates think is so
much better).

And, if I understood, the only case in which either Tim or Steve proposed
using Go To was _in conjunction with error handling_. If you do not, you are
very likely to find yourself including unnneccesary layers of conditions
just to avoid GoTos in case of error and clear need to "quit right now".
Unneccesary layers of conditions will make the code harder to read/follow
and be more conducive to the introduction of errors than a few GoTos.

Larry Linson
Microsoft Access MVP

Actually, I also often advocate using Goto to jump to a clean-up/exit block,
even when no error handling code exists in the procedure.

[jimfortune]

Steve Jorgensen wrote:

Actually, I also often advocate using Goto to jump to a clean-up/exit block, even when no error handling code exists in the procedure.

I think unconditional exclusion of GoTo's (space omitted) has served
it's purpose of eliminating the unorganized spaghetti code that
prevaled under BASIC and FORTRAN. GoTo was certainly good at making
code confusing and unstructured. That kind of coding is long gone (I
hope) so I won't malign any programmer who has a decent reason for
using it. I usually rewrite control structures to avoid GoTo since
it's nearly always possible to do that. In certain cases I guess I'd
even include not having the time to rewrite the control structure as a
valid reason for temporarily having a GoTo. The idea of using GoTo to
jump to a clean-up/exit block won't draw any criticism from me either.
Just allow me to decide how many times I need to duplicate clean-up
code before using it :-). You could even use a GoSub ... Return to run
the clean-up before exiting. Someone in this NG mentioned that it only
takes a few lines of code to allow a called Sub to access the variables
of the calling routine. I should have followed up on that.

James A. Fortune

People rationalize traffic laws. Police take them literally. Choose
wisely.

[David W. Fenton]

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

If ysnInitialize Then GoTo closeDB Then
If Not blnIsDbOpen Then Set dbCurrent = CurrentDb()
Else
If blnIsDbOpen Then dbCurrent.Close
Set dbCurrent = Nothing
End If

The first line of your code block is nonsense.

--
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:7u******** *************** *********@4ax.c om:

Actually, I also often advocate using Goto to jump to a
clean-up/exit block, even when no error handling code exists in
the procedure.

A guard clause that is the first thing in a procedure doesn't need
to jump to the clean-up/exit block -- Exit Sub/Function is fine
there, since if the guard clause is the first thing, there are no
structures to clean up.

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

[Steve Jorgensen]

On Thu, 24 Feb 2005 19:50:35 GMT, "David W. Fenton"
<dX********@bwa y.net.invalid> wrote:

Steve Jorgensen <no****@nospam. nospam> wrote in
news:js******* *************** **********@4ax. com:

If ysnInitialize Then GoTo closeDB Then
If Not blnIsDbOpen Then Set dbCurrent = CurrentDb()
Else
If blnIsDbOpen Then dbCurrent.Close
Set dbCurrent = Nothing
End If

The first line of your code block is nonsense.

Yes, it's a typo. it should read just "If ysnInitialize Then".

[Steve Jorgensen]

On Thu, 24 Feb 2005 19:53:14 GMT, "David W. Fenton"
<dX********@bwa y.net.invalid> wrote:

Steve Jorgensen <no****@nospam. nospam> wrote in
news:7u******* *************** **********@4ax. com:

Actually, I also often advocate using Goto to jump to a
clean-up/exit block, even when no error handling code exists in
the procedure.

A guard clause that is the first thing in a procedure doesn't need
to jump to the clean-up/exit block -- Exit Sub/Function is fine
there, since if the guard clause is the first thing, there are no
structures to clean up.

Guard clauses are not always at the absolute top. Sometimes, they are
checking initial state conditions that cannot be determined prior to
initializing the objects necessary to check them. These objects must be torn
down. I do try to avoid the issue, but the cure for that is sometimes worse
than the disease.