For Best Practices, each procedure should end at its bottom. This ensures all cleanup code (normally at the bottom) is executed and makes it easier for future developers (which may be you) to maintain.
VB6/VBA offers the ability to use the Exit command to leave a procedure at any point:
While this is appropriate at the bottom of the procedure where you may have error handling code, itís problematic if used in the middle of this procedure.
When a procedures exit in its body, all the code after it is not executed, and control jumps immediately back to the calling procedure.
For complex, long procedures with lots of loops and If statements, it's very easy to miss a hidden Exit command and not realize the flow could quit right in the middle. By avoiding the use of Exit commands in the middle of a procedure, you eliminate the need to remember or look for such instances which often cause bugs.
In the simple example below, an Exit Sub jumps out of the code while itís moving through a recordset. While the example is trivial, one may have code searching for a particular record and exiting when itís found. If itís embedded within multiple IF statements, FOR loops, etc. it may be easy to miss and be the cause of bugs:
Sub SampleExit() On Error GoTo PROC On Error GoTo PROC_ERR Dim rst As ADODB.Recordset Set rst = New ADODB.Recordset rst.Open "Msysobjects", CurrentProject.Connection Do While Not rst.EOF Debug.Print rst![Name] If rst![Name] = "Modules" Then Exit Sub ' <------ Avoid this End If rst.MoveNext Loop PROC_EXIT: Set rst = Nothing Exit Sub ' <------ This is okay PROC_ERR: MsgBox Err.Description, vbCritical, "Error occurred" Resume PROC_EXIT End Sub
At the bottom of the procedure in the PROC_EXIT section, it is appropriate to leave the procedure with an EXIT command to prevent the error handling section (PROC_ERR) from executing.
The use of these exit commands in the body of the procedure is considered lazy programming and should be replaced with the use of flags (variables) that tell the subsequent code to not execute and get to the bottom of the procedure.
In the example, we can do this by creating a boolean variable and setting it to True when the record is found. The Do Loop checks this variable, and ends when it becomes True. Control then goes to the end of the Do..Loop.
Sub SampleExit() On Error GoTo PROC_ERR Dim rst As ADODB.Recordset Dim fFound As Boolean fFound = False Set rst = New ADODB.Recordset rst.Open "Msysobjects", CurrentProject.Connection Do While Not rst.EOF And Not fFound Debug.Print rst![Name] If rst![Name] = "Modules" Then fFound = True End If rst.MoveNext Loop ...
If there were other commands after the Loop line, you could use fFound variable to either run or not run the appropriate code.
By avoiding the use of EXIT commands in the body of your procedures, youíll make your life, or the life of the next person assigned to maintain your application, much nicer. This is especially important for long, complex procedures, where subsequent developers will have to know, or discover the hard way, that they need to examine every line of code to see if an unexpected exit occurs.
One feature of our Total Access Analyzer program is its formatted module printout reports which bracket and indent your code so you can easily see loop and procedure exits. This lets you better understand existing code so you can decide if you need to fix it.
A feature of Total Access Analyzer is its detection of these Exit commands in the body of your procedures. Itís one of the 350+ types of Best Practices detected in your MS Access applications and VBA code.