Using Exit Sub (1 Viewer)

[DNewman]

I am a self-taught Access VBA person.
Sometimes I find the 'need' to exit a subroutine from within a control 'loop' e.g. if.. then..else with... while... et al.

I suspect this is 'bad form' but is there any 'cost' in doing this?

There presumably will be if objects have been set and are not reset to Nothing. In this case it presumably is not a problem resetting to Nothing outside a With.. - what about inside a with..??

 

[Kevin320]

As you indicate, some may consider this 'bad form', and if they do, I'd be curious to hear about it. I do this all the time. When I do, I simply try to ensure I close any open recordsets, set things to nothing, and set warnings back to true. Again, I'm curious to see if anyone has reasons to indicate this is bad form and something to avoid. If so, I hope there are suggested alternatives.

 

[pbaldy]

I typically use error handling so instead of Exit Sub I'd have GoTo ExitHandler. All of the clean up stuff would be there, so it always gets done. An example if necessary:

http://www.baldyweb.com/ErrorTrap.htm

 

[MarkK]

There are other arguments, but typically, Exit Sub is not required. Have you seen code like this?

If Something Then
   Do Something
   Exit sub
ElseIf SomethingElse Then
   Do SomethingElse
   Exit Sub
End If

Here's code that does the same thing

If Something Then
   Do Something
ElseIf SomethingElse Then
   Do SomethingElse
End If

Exit sub, how it is most commonly used, is not required, and anything that is not required, in code, should be omitted.

 

[Kevin320]

MarkK,

I don't believe the OP is talking about the scenario you describe, and I know I'm not. Instead, it's a situation wherein criteria are met or not met prompting the need to exit the sub rather than continue running the sub. For example:

If Something Then
   Exit Sub
End If
 
Do other stuff
 
End Sub

In this case, with the criteria being met, we don't want to do the other stuff. In lieu of Exit Sub, we could use "If Something GoTo EndOfSub:", or write all of the other stuff in the Else statement, but that could get cumbersome. pbaldy has a good suggestion regarding ExitHandler, or we could put the other stuff in a different sub and simply call that sub, but using Exit Sub, at least in my uses, is efficient. I'm curious, as I believe the OP is, if there are any reasons not to use Exit Sub.

Thanks,

Kevin

 

[pbaldy]

I think Mark's point is that it could be:

If [COLOR="Red"]Not [/COLOR]Something Then
   Do other stuff
End If

And the exit wouldn't be necessary. That said, sometimes in larger, more complicated procedures I find it easier to follow with a test at the top with an exit than burying things in an Else, especially if there are multiple If/Then blocks. In other words

If Something Then
  do something
  GoTo ExitHandler
End If

lots more code

rather than

If Something Then
  do something
Else
  lots more code
End If

Though I often have comments at the end so I know what's going on:

lots of code
      End If  'end test for something
    End If  'end test for something else
  End If  'end some other stupid test

 

[DNewman]

Yes - I see the point that it may be possible to avoid Exit Sub.
I just find that sometimes my flow of logic seems more transparent with (sparing?) use of Exit Sub notwithstanding lots of comments.

Why make things more complicated than they need to be? ((Exit Sub is there, so why not use it - especially if it means avoiding re-writing a pile of code)

The good news is that nobody is telling me that, provided you tidy up properly, there is still a 'cost' to abandoning ship in mid flow.

 

[gemma-the-husky]

sometimes exit sub, or a goto is an easy way or terminating a complex construct.

not a problem, if you control it properly. After all, it's hardly any different to the assembly/machine code that the compiler generates.

 

[MarkK]

I think there's a simplicity advantage to writing routines that have one entrance and one exit. I think that if you are tempted to have multiple exits in a routine, your routine is probably too long, and should be broken into a greater number of simpler routines.

My rule of thumb is that one routine should do one thing. Typically I will only have one loop in a routine, or only open one recordset. If there needs to be another loop, or a new recordset, I would do that in a subroutine. My modules look a lot like this, with lots of short, succinctly named subroutines (and Property Gets), so each single step is clearly named, easy to debug, and I never do Exit Sub.

sub Controller
   subtask1
   subtask2
   finaltask
end sub

sub subtask1
   does one thing
end sub

sub subtask2
   does one other thing
end sub

sub finaltask
   also only does one thing
end sub

IMO, simplicity, clarity, and reliability increase as the length of your subroutines decreases.

 

[Galaxiom]

I prefer the constructs that avoids Exit Sub.

Exit Sub is like jumping out the window. Better to leave by the door.

I also concur with Mark's one Sub, one job construction. It is much easier to maintain.

I also completely encapsulate subs and pass everything they need via arguments. I avoid constructs that manipulate global or module wide variables because the declaration line does not fully describe the interface.

Changing a variable other than through the declared interface hides the actions of a procedure from anyone maintaining the code and destroys portability.

If multiple variables must be manipulated by a procedure then they can be passed as ByRef arguments. The ByRef indicates the parameter will be manipulated by the sub.

 

[smig]

I typically use error handling so instead of Exit Sub I'd have GoTo ExitHandler. All of the clean up stuff would be there, so it always gets done. An example if necessary:

http://www.baldyweb.com/ErrorTrap.htm

Try to void Exit Sub if you can.
In any case I think you should adopt what pbaldy said. It will also clear things in case of an error.