Proper use of lbl_Exit:

[BrianHoard]

As our small team learns VBA, we get a lot of info from the folks on this forum and their websites. I like to understand every line of code, and not blindly copy/paste from the internet.

As I review several of our scripts, I keep seeing this "lbl_Exit:" From my Windows cmd scripting, this looks like it may be the target for a GOTO command? But I'm seeing it just listed in the script with nothing else pointing to it. Which I'm guessing will just run the commands under this label when it appears in the script.

Can someone explain what this is about, or where I can learn more about it, and even if I need it at all?

Here's is one of several similar scripts we've created that uses lbl_Exit: But nothing in the script calling it.



I'm guessing setting a variable to Nothing clears it, which seems like a good thing to do. Not sure if that is necessary, as Exit Sub and End Sub would probably do that anyways, right?

Sub bhh_removeCrossRefs()
  ' Do what Ctrl shift F9 does, removing cross-references.
  
  Dim i as Integer
  Dim oStory As Range
  For Each oStory In ActiveDocument.StoryRanges
    For i = oStory.Fields.Count To 1 Step -1
      If oStory.Fields(i).Type = wdFieldNoteRef Then
        Debug.Print (oStory.Fields(i).Type)
        oStory.Fields(i).Unlink
      End If
    Next i
  Next oStory
  
  lbl_Exit:
    Set oStory = Nothing
    Exit Sub
    
End Sub ' bhh_removeCrossRefs

[Italophile]

Labels are typically used with GoTo and an Exit label would typically be used with some error handling code so that there is a single exit point. I have known some programmers use them simply to mark sections of code, though. In this case you don’t need the label, though it is neither useful nor doing any harm.

Setting an object variable to nothing is a habit some of us long timers have because VBA has/had the reputation of being a sullen teenager when asked to clean up its room. In theory VBA should release allocated memory when an object variable goes out of scope, but that didn’t always happen. By explicitly destroying the object you keep things clean and ensure allocated memory gets released.

[BrianHoard]

Thanks for the help. Makes sense.

[gmaxey]

Brian,


I do that a lot and I've posted a lot of code here with the lbl_Exit statement.


I use phrase express and when I type sam in a VB code pane, I get:


Sub ScratchMacro()
'A basic Word macro coded by Greg Maxey

lbl_Exit:
Exit Sub
End SUb


When I am reviewing other people's (often to fix), I usually add the lbl_Exit statement as a flag to remind me that I've already looked at that procedure.


Often, and in those cases, it has no functional value and only there as style. Some folks from the old school used to practice never let a procedure run to the End Sub line. Exit first. Why, I don't know but it just became as habit for me.

To make is useful, I would do something like this:

Sub ScratchMacro()
'A basic Word macro coded by Greg Maxey
Dim oRng as Range
Set oRng = ActiveDocument.range
On Error GoTo Err_Handler
Err.Raise 6
lbl_Exit:
Set oRng = Nothing
Exit Sub
Err_Handler:
Msgbox Err.Number & " " & Err.Description
Resume lbl_Exit
End Sub

[BrianHoard]

Thanks Greg, I have learned a lot from your websites.
In our scripts, I have managed to crash Word on occasion. I wonder if doing this error handling would prevent that, and instead of crashing, follow this code to a clean exit. That would be nice.