general 'exit sub' question

  • Thread starter Thread starter Jon
  • Start date Start date
J

Jon

I think I read somewhere once that said you should not do this:

whateverSub
If somecondition is false THEN
Exit Sub

Else
do whatever it is you will do if somecondition is true
go on with rest of sub

End Sub


I think I read where you shouldn't just Exit Sub in the middle of a If clause,
Is that true? If true, then you should substitute GoTo for Exit Sub, and jump
to a label where you Resume (the Resume being just before the End Sub)?

I hope that makes sense.....
Thanks
 
In older languages, including Basic, the call stack could not keep track of
jumping in and out of sub routines at random. In VBA and other modern
languages, the compiler handle this much better. It is really more
structured coding practices that dictate these rules.

The GoTo in all languages is frowned upon. So is the Exit Sub.

You can certainly get along well without ever using a GoTo. It can easily
create confusion for the person trying to follow your code. The only form it
should be use for is the On Error GoTo and in an Error Handler to go to the
procedure's Exit tag.

There is debate on the Exit Sub. I personally don't have a serious
objection to it. Purist in the Structured Coding world will froth at the
mouth when I say that, but in my opinion, it can be used to simply the code.
The only time I use it is to exit the sub when excessive nested If's would be
required to avoid it.

With that said, it can almost always be avoided by making all your
procedures as small as possible. For example, break up a large task into
small pieces. Instead of

Call DoEveryThingInAGiantSub

You might use.

Call CreateRecordSet
Call SetUpToStart
Do While Not rst.EOF
Call ProcessARecord
Call CalcTotals
Loop
Call CleanUp
 
Thanks for the reply. So, I think you're saying to try and structure the sub
so that IF condition is true, then either have my code or have a Call to another
sub, ELSE nothing................

If Isnull(me.sometextbox) Then
me.undo
cancel=true
msgbox "Required field"

ELSE
'do nothing
End If
End Sub

I guess I'm still not too terribly clear on whether to use Exit Sub or not. I
kinda see what you're talking about, though.

Just trying to 'fill in the gaps' of my (limited) coding knowledge.

Thanks
 
Asking questions and experimenting is how we get there. In your example, the
Else is not necessary. Also, to make code easier to read, use indentation.
Different people have different ways of doing it, but here is a summary of
how I usually do it.
Procedure declarations, Tags, and Dims are all left justified. Although
some will disagree, it is the better practice to dim all variables at the top
of the sub.

Private Sub IgnoreUserInput
Dim strSomeString As String

IgnoreUserInput_Exit:

IgnoreUser Input_Error:

Executeable code starts with the first indent. Each time you use a
conditional, add an indent.

If Isnull(me.sometextbox) Then
me.undo
cancel=true
msgbox "Required field"
Else
If Len(Me.SomeTextBox) < 3 Then
MsgBox "Must Be At Least 4 Characters"
End If
End If

See how easy that is to follow?

As to the Exit Sub. Use your judgement. If you can avoid doing it, then
do. If it would complicate the code, Use it. One other technigue is to
write all procedures as Functions. Then you can have the function return a
code that tells you what to do next.

If CheckClientAge(Me.ClientId) > 65 Then
If Not ApplySeniorBenefits Then
MsgBox "Unable to Apply Senior Benefits"
Else
blnResult = UpdateClientRecord
End If
End If
If blnResult = True Then
Me.SomeControl.SetFocus
Else
Me.AnotherControl.SetFocus
End If

In the example above CheckClientAge, ApplySeniorBenefits, and
UpdateClientRecord are all function that return a value. CheckClientAge
returns an integer and the others return a boolean. This helps keep your
code easy to read.

Hope this helps, good luck.
 
Thanks for the tips..

Jon


Asking questions and experimenting is how we get there. In your example, the
Else is not necessary. Also, to make code easier to read, use indentation.
Different people have different ways of doing it, but here is a summary of
how I usually do it.
Procedure declarations, Tags, and Dims are all left justified. Although
some will disagree, it is the better practice to dim all variables at the top
of the sub.

Private Sub IgnoreUserInput
Dim strSomeString As String

IgnoreUserInput_Exit:

IgnoreUser Input_Error:

Executeable code starts with the first indent. Each time you use a
conditional, add an indent.

If Isnull(me.sometextbox) Then
me.undo
cancel=true
msgbox "Required field"
Else
If Len(Me.SomeTextBox) < 3 Then
MsgBox "Must Be At Least 4 Characters"
End If
End If

See how easy that is to follow?

As to the Exit Sub. Use your judgement. If you can avoid doing it, then
do. If it would complicate the code, Use it. One other technigue is to
write all procedures as Functions. Then you can have the function return a
code that tells you what to do next.

If CheckClientAge(Me.ClientId) > 65 Then
If Not ApplySeniorBenefits Then
MsgBox "Unable to Apply Senior Benefits"
Else
blnResult = UpdateClientRecord
End If
End If
If blnResult = True Then
Me.SomeControl.SetFocus
Else
Me.AnotherControl.SetFocus
End If

In the example above CheckClientAge, ApplySeniorBenefits, and
UpdateClientRecord are all function that return a value. CheckClientAge
returns an integer and the others return a boolean. This helps keep your
code easy to read.

Hope this helps, good luck.
Click to expand...
 
Back
Top