[2005] Return vs. Exit Sub

[Blakk_Majik]

I've seen both used to exit a routine after an error, so I can safely assume both statements do the same thing (in terms of handing control back to the caller).

My question is, does anyone prefer one over the other? I've become quite used to using Return, but I can see how Exit Sub might be better for readability, since Return can also be used in a function to send a value back to a caller.

I heard Return is more common across other languages though.

Any thoughts?

Mods feel free to move to general developer if necessary. I just put it here because the topic is specific to VB.Net.

[RobDog888]

On the top level they are both the same but if you are in a Sub routine then it depends on your code block as you shouldnt have more then one exit point and using either is "ok".

Return is used to "return a value" which is used in a Function but return with a value is optional which is why it also works in a Sub.

[talkro]

Personally I use them for consistency, when I write a sub and need to get out a t some point I use exit sub. On the other hand if i'm in a function then I use return (actually have no other choice here thought lol)

[RobDog888]

Well you could use Exit Function if you are assigning the function name the return value.

Public Function Test(ByVal Blah As Integer) As Boolean
    'Whatever
    If 1 = 2 Then
        Test = False
        Exit Function
    Else
        Test = True
        Exit Function
    End If
End Function

[alex_read]

Return is used to "return a value" which is used in a Function but return with a value is optional which is why it also works in a Sub.

Java and C++ I believe both use the return call. Sub's in vb are void's in C++ - that is, functions without a return value anyhow.

It would be interesting to see the MSIL behind both of the calls - but I'd imagine at IL level they'd be exactly the same coding.

Personally I use the return call, but ONLY at the end of a function (usually I will keep a method-level variable updated on the method return value and only return that at the end of the function). Having IF...Then statements and keeping the flow from top to bottom of the method code I find is much easier rather than figuring out why code execution suddenly halts and pops out of a method 1/2 way through it (or a debugging breakpoint line never gets hit due to the same reason).

[RobDog888]

Yes, that helps greatly when debugging to follow the standard of only one exit point in a procedure.

[dbasnett]

Just off the top of my head, I seem to remember something about returns and optimization.

[jmcilhinney]

Never use Exit Sub or Exit Function. That's easy to remember.

All functions should complete at a Return statement. Many people believe, as do I, that it is preferable to have a single Return statement at the end of the method with all execution paths leading to that line.

Procedures (Subs) can just exit naturally at the End Sub statement. If you want to exit early then you can use a Return statement again, but don't specify a return value. That said, it is again considered preferable by many not to have multiple exit points in a procedure either, but rather to make all execution paths lead to the End Sub line. For instance, rather than doing this:

Private Sub DoSomething()
    If someCondition Then
        Return
    End If
 
    'Do something here.
End Sub

it is preferable to do this:

Private Sub DoSomething()
    If Not someCondition Then
        'Do something here.
    End If
End Sub

The net result of those two code snippets is the same but the second one provides a single exit point for the method. As methods get more complex that becomes more maintainable.

That said, there are times where forcing a single exit point can make code more complex by creating additional levels of nested If statements. In that case it's worth considering breaking the method up into multiple methods if it's practical. If it's not then providing multiple exit points is acceptable. Remember, the idea of a single exit point is to improve maintainability. If doing so actually hinders maintenance then it defeats the purpose, so that would be the exception to the rule.

Edit: Having read some other posts in the thread now I see that I agree with alex.

[alex_read]

Wow, really? Cool!

Dbasnett's post intrigued me there, and I have uncovered this one - however evil, it's good (and a little confusing) that the retun does perform better than an exit, though I haven't found why, but interesting stuff to see!

Return

Code that uses the Return statement is optimized better than code using Exit Function, Exit Property, or Exit Sub. For functions use Return with an expression. For Subs and Properties use Return without an expression.

[dbasnett]

that is it. what i didn't get:
are End Function / End Sub returns or exits?

[RobDog888]

Edit: Having read some other posts in the thread now I see that I agree with alex.

... you shouldnt have more then one exit point ...

I guess I am transparent today

[Blakk_Majik]

Yes, that helps greatly when debugging to follow the standard of only one exit point in a procedure.

But if I have a form with 5 or 6 boxes consisting of combo boxes, textboxes, etc., how can I have only one exit point?

If someone has entered bad data into a field, I need to refocus on that field immediately, there is no need to continue with the validation.

Unless there is something elementary that I have completely missed, I need an exit point every time validation fails.

[ProphetBeal]

If you are doing validation you should really be in a Try...Catch block and in that case you could Exit Try if a validation fails (which in theory would take your single exit point)

[alex_read]

If validationcheck1 = true
    ' Carry on processing, perform validation check 2
    If validationcheck2 = true then
        ' another inner statement to continue positive execution routines...
    end if
End if
' Code continues at this point if validation check 1 wasn't true...
End Sub

... you shouldnt have more then one exit point ...

Ohh yeah! Well I'll acknowledge you Rob! - post was there 1st, must admit I missed that the 1st time round - maybe put it in 50pt bold?

[RobDog888]

But if I have a form with 5 or 6 boxes consisting of combo boxes, textboxes, etc., how can I have only one exit point?

If someone has entered bad data into a field, I need to refocus on that field immediately, there is no need to continue with the validation.

Unless there is something elementary that I have completely missed, I need an exit point every time validation fails.

You can do it many ways.

Perform the check at the lostfocus event of each control or just validate at the button click that processes them.

Also, use an If Then code block or a Try Catch code block. Either way they dont need to exit from them and just call a process sub upon valid validation otherwise it falls through and exits the sub at the closing procedure line.

:woot: acknowledged

[Blakk_Majik]

If validationcheck1 = true
    ' Carry on processing, perform validation check 2
    If validationcheck2 = true then
        ' another inner statement to continue positive execution routines...
    end if
End if
' Code continues at this point if validation check 1 wasn't true...
End Sub

This code is fine, but it does not give enough information. If a part of the validation fails, and it just exits the sub, what information will it give? How will the user know that validation check 2 is the one that failed? How will they know what to do so that validation check 2 doesn't fail again?

I suppose I'm thinking about it from a user standpoint. If I put the wrong value in the name textbox, tell me and let me change it. Don't just tell me the app could not verify my input, or throw some exception that the average user will not understand.

[ntg]

Having declared the following methods:

    Private Sub doReturn(ByVal s As String)
        If s = "" Then
            Return
        End If
        Console.WriteLine(s)
    End Sub

    Private Sub doExitSub(ByVal s As String)
        If s = "" Then
            Exit Sub
        End If
        Console.WriteLine(s)
    End Sub

We get the following IL:

.method private instance void  doReturn(string s) cil managed
{
  // Code size       23 (0x17)
  .maxstack  8
  IL_0000:  ldarg.1
  IL_0001:  ldstr      ""
  IL_0006:  ldc.i4.0
  IL_0007:  call       int32 [Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.Operators::CompareString(string,
                                                                                                                    string,
                                                                                                                    bool)
  IL_000c:  ldc.i4.0
  IL_000d:  bne.un.s   IL_0010
  IL_000f:  ret
  IL_0010:  ldarg.1
  IL_0011:  call       void [mscorlib]System.Console::WriteLine(string)
  IL_0016:  ret
} // end of method Form1::doReturn


.method private instance void  doExitSub(string s) cil managed
{
  // Code size       23 (0x17)
  .maxstack  8
  IL_0000:  ldarg.1
  IL_0001:  ldstr      ""
  IL_0006:  ldc.i4.0
  IL_0007:  call       int32 [Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.Operators::CompareString(string,
                                                                                                                    string,
                                                                                                                    bool)
  IL_000c:  ldc.i4.0
  IL_000d:  bne.un.s   IL_0010
  IL_000f:  ret
  IL_0010:  ldarg.1
  IL_0011:  call       void [mscorlib]System.Console::WriteLine(string)
  IL_0016:  ret
} // end of method Form1::doExitSub

So the compiler in both cases jumps conditionally to a label and inserts a return opcode if the jump isn't executed.

Interestingly enough, the method:

    Private Sub doNoReturn(ByVal s As String)
        If s = "" Then
            Return
        Else
            Console.WriteLine(s)
        End If
    End Sub

produces the following IL:

.method private instance void  doNoReturn(string s) cil managed
{
  // Code size       23 (0x17)
  .maxstack  8
  IL_0000:  ldarg.1
  IL_0001:  ldstr      ""
  IL_0006:  ldc.i4.0
  IL_0007:  call       int32 [Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.Operators::CompareString(string,
                                                                                                                    string,
                                                                                                                    bool)
  IL_000c:  ldc.i4.0
  IL_000d:  bne.un.s   IL_0010
  IL_000f:  ret
  IL_0010:  ldarg.1
  IL_0011:  call       void [mscorlib]System.Console::WriteLine(string)
  IL_0016:  ret
} // end of method Form1::doNoReturn

which is the same as in both previous cases. So I'd say that use of Return, Exit Sub or nested IFs is purely a matter of personal/team preference for methods that don't return a value.

[alex_read]

Well blimey that was a simple sample , ok try this then

Dim validityErrorMessageString as string = string.empty
If textbox1.text= string.empty then
    validityErrorMessageString = "Textbox Empty!"
    If textbox1.text.trim.length < 2 then
        validityErrorMessageString = "Text entered was only 1 character"
    end if
End if

If validityErrorMessageString = string.empty then
    return "All OK!"
Else
    return validityErrorMessageString 
End If
End Sub

[alex_read]

Fantastic stuff NTG , I was far too lazy to do that.

I imagined that would have been the case originally, but was fascinated when I heard mention the methods did perform differently, guess you can't believe everything you read on the net! (that wasn't aimed at dbasnett, rather at getdotnetcode.com who I found that above quote from).

Thanks for clearning that one up and posting the sample, very useful stuff!

[jmcilhinney]

But if I have a form with 5 or 6 boxes consisting of combo boxes, textboxes, etc., how can I have only one exit point?

If someone has entered bad data into a field, I need to refocus on that field immediately, there is no need to continue with the validation.

Unless there is something elementary that I have completely missed, I need an exit point every time validation fails.

Yes, you are missing something fundamental. You should be validating each control in its own Validating event handler. If you want to validate the entire form, say on a Button Click, then you call the form's ValidateChildren method. This will raise each control's Validating event in turn. If any control fails validation, i.e. you set the e.Cancel property to True in the Validating event handler, then validation halts there and that control receives focus. Here's an example of that mechanism in a Login dialogue:

Private Sub userNameText_Validating(ByVal sender As Object, _
                                    ByVal e As System.ComponentModel.CancelEventArgs) Handles userNameText.Validating
    If Me.userNameText.Text.Trim() = String.Empty Then
        MessageBox.Show("Please enter a user name.", _
                        "Required Field", _
                        MessageBoxButtons.OK, _
                        MessageBoxIcon.Warning)
        e.Cancel = True
    End If
End Sub
 
Private Sub passwordText_Validating(ByVal sender As Object, _
                                    ByVal e As System.ComponentModel.CancelEventArgs) Handles passwordText.Validating
    If Me.passwordText.Text.Trim() = String.Empty Then
        MessageBox.Show("Please enter a password.", _
                        "Required Field", _
                        MessageBoxButtons.OK, _
                        MessageBoxIcon.Warning)
        e.Cancel = True
    End If
End Sub
 
Private Sub loginButton_Click(ByVal sender As Object, _
                              ByVal e As EventArgs) Handles loginButton.Click
    Me.ValidateChildren()
End Sub