Exit method early

I know this is probably a really basic question but I have a method that I want to exit early (eg not at the end of the method) and it does not return anything so how can I exit the method? Thanks

Return
Exit Sub

take your pick

So can you use Return even if you dont have a return type specified? I didnt even think about using Exit Sub as it was a method. Thanks

Everyone has different preferences. I’ll share mine since, naturally, they are the right ones. :stuck_out_tongue:

I check parameters at the top of the method and, if they are faulty or deficient, raise an exception or return early, whatever is appropriate. After that, I try to return once at the bottom of the method using if statements and flags, although in some cases it makes sense to return early. In those cases, I will clearly mark it with a comment like // EARLY RETURN in case, later, I want to add additional code below the return that I expect to run.

Thanks Kem.

Can you also return from an action early using Return?

[quote=361437:@Nathan Wright]Thanks Kem.

Can you also return from an action early using Return?[/quote]
Early return will stop whatever method / function / event you’re in, you can use it anywhere.

I try to avoid what Kem is writing about because it creates big if statements that are sometimes nested multiple levels deep with a persistent variable throughout the whole method. I return out of a method as early as I can for my own sanity.

Thanks Tim

On entry methods should, at least in debug mode, assert that params are specified as expected (types, values, not nil, etc)
And break right there if they are not so issues can be caught early & often

In released code returning right there may be appropriate
But now the caller has to be written to handle possibly “bad” returns as well

I have no issue with a RETURN at any point you cannot carry on as this avoids highly indented code with piles of flag values etc to get to “one return to rule them all”
I will say that for this sort of thing I will write a check like

    if condition = false then
        return
    end if

simply because a one liner is WAY too easy to overlook

And yes ANY code can be exited early with RETURN (it may require a return value if the method/event returns a value)

Yes, that’s certainly a danger and should be avoided. I prefer a single flag, something like this:

dim keepGoing as boolean = true

if keepGoing then
  // Processing
end if

if keepGoing then
  // More processing
end if

// etc

return value

That prevents long nested If statements and ensures that I always know that code will be touched at least. Later, I can do this without concern:

if keepGoing then
  // Processing
end if

// Other processing regardless of keepGoing

if keepGoing then
  // More processing
end if

But again, these are different ways of tackling the problem and your approach can vary from method to method as appropriate.

I avoid flag variables like this where possible

I do as well.

But now I’m interested, Kem. In your example, the way it’s written, you might as well use a return. Was this just a simplified example, or is there a reason you write the method as you do?

depending on the process I will sometimes use a “success” flag, if the method needs to call a series of sub-methods

Function myFunction as Boolean
dim success as boolean = true
if success then success=method1()
if success then success=method2()
if success then success=method3()
return success
end function

yes, the first IF is redundant, but I put it there is case for some reason I need to change the order of the sub-methods

I use this method alot with Database routines… as it preserves the last database errorcode/message and basically aborts further processing at the first error

Also I prefer that functions and methods have ONE way IN and ONE way OUT

[quote=361456:@Tim Parnell]I do as well.

But now I’m interested, Kem. In your example, the way it’s written, you might as well use a return. Was this just a simplified example, or is there a reason you write the method as you do?[/quote]

Experience. In long methods, I’ve gotten burned by early returns, but I admit that part of that might have been inexperience. I am a better programmer today with a better grasp on oop concepts than in the past.

While I still think it’s a good habit, I understand those who disagree.

You can collapse this into a single line since Xojo does short circuit evaluation of boolean expressions:

Return method1() And Method2() And Method3()

[quote=361443:@Norman Palardy]

if condition = false then return end if [/quote]

I also use this, mostly because I can set a break point on the return line.

Thats another reason to use that form

[quote=361448:@Kem Tekinay]That prevents long nested If statements and ensures that I always know that code will be touched at least. Later, I can do this without concern:

if keepGoing then
  // Processing
end if

// Other processing regardless of keepGoing

if keepGoing then
  // More processing
end if

[/quote]

If Kem had used a return in the first IF, the “Other processing regardless of keepGoing” code would not have been executed. By using the keepGoing flag, that code is guaranteed to be executed, regardless of any errors. That is sometimes somewhat important (read: very important!). I have been burned by early returns, but I keep using them. Perhaps I should learn.

That construction suggests that there is something in the first “if keepGoing block” that sets some conditions that are checked in the code that follows it outside of the keepGoing block
Otherwise the code seems it could be structured

// Other processing regardless of keepGoing

if keepGoing then
  // Processing
  // More processing
end if

and again an early return seems viable instead of the flag

[quote=361467:@Andrew Lambert]You can collapse this into a single line since Xojo does short circuit evaluation of boolean expressions:

Return method1() And Method2() And Method3()[/quote]

While technically true, I personally prefer to avoid that structure because:

  • It is not intuitive to all programmers who see it for the first time
  • You can’t set debug breakpoints or step the code quite as easily

[quote=361576:@Douglas Handy]While technically true, I personally prefer to avoid that structure because:

  • It is not intuitive to all programmers who see it for the first time
  • You can’t set debug breakpoints or step the code quite as easily[/quote]

Chaining method calls is only one example, and I’d agree that it’s not the best example. However, short circuiting applies to all expressions that use more than one boolean operator.