Legal ways to exit if/endif block (1 Viewer)

[ListO]

Greetings

I know this is kind of a basic question, but I'm having trouble finding the answer.

Does it matter how an If / Endif block is exited? Would the following code cause problems when executed a lot of times?

I'm concerned that when condition1 and condition2 are true, I'm exiting both IF blocks without passing their End If code, thus leaving debris in the processor.

I have a number of places in my code with two or three nested IF blocks. It is all working nicely, but every now and again things seem to choke up and require a restart, after which everything is fine. Until it isn't again. I can be working in the application for hours on end without problems.

If I'm not exiting correctly, what IS the correct way to exit nested IF blocks?

If condition1 = True then
   Dosomething
   If condition2 = True then
       Dosomething
       Goto GetOut
   End If
   Do_anotherthing
   Do_anotherthing
End If

Domorethings_that_I_don't_want_done_if_condition2_is_True

GetOut:
Exit function

 

[ChrisO]

G’day List0.

While a lot of programmers dislike instructions like ‘GoTo GetOut’ there is no reason that it should cause the problems you are having, in fact, it is preferable to doing an ‘Exit Sub’ on that line. The way you are using it at least takes you to a common exit point where some cleanup can be done if required.

The real problem, as far as I see it, is not the going to some other line of code but rather knowing how we got there.

However, I think the logic could be rearranged to avoid it altogether.

Regards,
Chris.

 

[ListO]

I agree with your philosophical approach - there are always ways we can get things done, but are they the most elegant ways? I struggle with this always.
Thanks for the comments.

 

[rapsr59]

Hi ListO

I don’t think you should have any problem using a Goto Statement within nested If/Then statements. I never have. I’ve programmed Basic since 1985 using Abasic in the 80’s and VBA since 1996 and, as I said. I’ve never a encountered a problem using Goto’s to exit an If / Then statement. I guess there is always a possibility there might be some problem, but as I said I’ve never encountered one.

As coded you might consider using an Exit Function as suggested.

If the code between the If/Then statements is lengthy, I like to use Gosubs. To me, they are a very logical way of placing code in a different place in order to keep the If/Then statements clean and Simple

For example:

[FONT=Times New Roman][SIZE=3]Private Function Example ()[/SIZE][/FONT]
 
[FONT=Times New Roman][SIZE=3]If A Then[/SIZE][/FONT]
[SIZE=3][FONT=Times New Roman]   Gosub DoFirst[/FONT][/SIZE]
[SIZE=3][FONT=Times New Roman]   If B then[/FONT][/SIZE]
[SIZE=3][FONT=Times New Roman]       Gosub DoSecond[/FONT][/SIZE]
[SIZE=3][FONT=Times New Roman]   End If[/FONT][/SIZE]
[FONT=Times New Roman][SIZE=3]End If[/SIZE][/FONT]
 
 
[FONT=Times New Roman][SIZE=3]Exit Function:[/SIZE][/FONT]
 
[FONT=Times New Roman][SIZE=3]‘----------------------------------Gosubs Go Here---------------------------------------[/SIZE][/FONT]
[FONT=Times New Roman][SIZE=3]DoFirst:[/SIZE][/FONT]
[SIZE=3][FONT=Times New Roman]  ‘Lots of Code Here[/FONT][/SIZE]
[SIZE=3][FONT=Times New Roman]  …[/FONT][/SIZE]
[FONT=Times New Roman][SIZE=3]Return[/SIZE][/FONT]
 
[FONT=Times New Roman][SIZE=3]DoSecond:[/SIZE][/FONT]
[SIZE=3][FONT=Times New Roman]  ‘Lots of Code Here[/FONT][/SIZE]
[SIZE=3][FONT=Times New Roman]  …[/FONT][/SIZE]
[FONT=Times New Roman][SIZE=3]Return[/SIZE][/FONT]
[FONT=Times New Roman][SIZE=3]‘----------------------------------End Of Gosubs-----------------------------------------[/SIZE][/FONT]
[FONT=Times New Roman][SIZE=3]End Function[/SIZE][/FONT]

This is just a suggestion.

Richard

 

[Banana]

Regarding GoTo and 'processor debris', I basically agree with ChrisO that even if your code used GoTo all over the places instead of other constructs, it wouldn't necessarily cause stability issue, though I pity the fool who try to follow the spaghetti code! Furthermore, I would bet that if we go all way to the binary level, we'd find that processor will do a lot of jumping around in the code, using pointers and addresses to keep track of where it is supposed to do something. Us being human would fail miserably if we were to actually code in binary, which is why we use programming language to abstract away all those menial pointer and address that the hardware uses in resolving the variables and the workflow. Thus, the processor has no special knowledge of "End If"; it can only execute the instruction it's been given in machine code which is something different from what we entered in the code.


But if there was a candidate for breaking that 'never say never' rule, Goto would be one. Mind you, I've only used it once to replicate other language's implementation of switch() (VB/VBA recognize those as Select Case statements). But I again agree with ChrisO, sometime it's not the question of logic branching but rather arranging your workflow so to make it unnecessary.

Few possible examples would be to:

1) separate out the dosomething1 and dosomething2 into their own procedures and execute them separately

2) perform everything for dosomething1 first, then test for condition2 and only do dosomething2 if true or allow the code to 'fall through' to the end of sub.



We also have to give some thoughts about how we want to branch our logic.

In case of testing for condition and expecting one result it's pretty straightforward. A single If/Then does just that.

But if we expect more than one result, we could either do that:

If condition1 = 1 Then
   ....
Elseif condition1 = 2 Then
  ....
Else
  ....
End If

But it would be more elegant to do this:

Select Case condition1
    Case 1, 3 
        .....
    Case 2, 4 To 6
        ....
    Case Else
        ....
End Select

Now all examples dealt with only one condition to tests, but suppose we had two conditions to test?

If the two conditions to be checked are independent then it's just two If/Then:

If Condition1 = 1 Then
   ....
Else
   ....
End If

If condition2 = 1 Then
    ....
Else
    ....
End If

The above can also be rewritten as:

If condition1 = 1 Then
    ....
ElseIf condition2 = 1 Then
   ....
Else
   ....
End If

Now I want to point out that while those two forms are similar, in second form, we only have one Else clause for the both conditions, whereas first form allowed us to perform Else (e.g. false or whatever) upon each condition separately. Which is the right form ultimately will depend on specifically how you want the logic to branch out. If you have no actions to take if the condition1 isn't met and want to go to the condition2 immediately, then the latter form may be a better fit. But if condition2 somehow depend on processing you've performed on condition1, whether it's been met or not, then the first form give you more control by having your own Else clause for each condition.

Finally, if we have multiple conditions with multiple results and all conditions are dependent on each other (which is *very* rare but not unheard of), then the answer is to use bitwise flags but that's a whole another topic.

The point being is that you should work out how your want your logic to branch out and make sure your path is the most direct . If you find yourself needing to checking the same condition twice, then it may be a sign that it needs to be reworked.

Taking your code, I would probably rewrite it to something like this:

If condition1 = True then
   Dosomething
   If condition2 = True then
       Dosomething
   [color=red]Else
       Domorethings_that_I_don't_want_done_if_condition2_is_True[/color]
   End If
   Do_anotherthing
   Do_anotherthing
End If

Mind you, that's just my best guess and assuming that there are no processing need to be already done for the "Domorethings_I_don't_want_to_do_if_condition2_is_true".

I hope this helps.

 

[ListO]

Hey, thanks for the tips. I find I don't often use the Else If very often - possibly that can help.

Your structural suggestions are appreciated.

-Curt

 

[Rabbie]

Having been an assembler programmer during part of my career I can confirm that there are hidden gotos generated by the compiler when it processes an If statement.

There wil be a jump generated at the IF statement when the condition is false to skip the True path code and a second jump over the Else part if that is applicable

 

[Rabbie]

As regard to the elegance or not of a particular solution the prime criterion IMHO is that the code is easy to understand. With the speed of modern computers you gain more by being able to grasp what is being done than by absolute speed of execution.

 

[gemma-the-husky]

i used to be very anal? about so-called good programming practice and tie myself in knots avoiding goto statements, and making sure iterations end gracefully - now i'm not so bothered - if its readable, gotos are often easier to follw - thats what a error handler does isnt it.

however i would still prefer to think about it, and do a proper

while condition
....
wend

than do a sloppy

for x = 1 to whatever
 if condition then goto jumpoutofloop
next
jumpoutofloop:

although i still have to do some 3GL programming and there are lots of instances of effectively this to iterate a file etc

readfirst
goto test

readnext

test:
 if eof goto endroutine
 processitem
 goto readnext

 

[dfenton]

however i would still prefer to think about it, and do a proper

while condition
....
wend

I'm not sure where I got this, but I think MS has been promoting DO LOOP in place of DO WHILE. I know that somebody authoritative told me that a few years ago (probably Michael Kaplan) and I switched over then. I'm not sure what the reason was, but his explanation made sense at the time.

For what it's worth!

 

[Banana]

Could we be talking about While..Wend and not Do While Loop?

I believe that While...Wend is a older construct which is still around for backward compatibility while the Do {Until | While} loops are the "preferred" statements.

All I can find, though is a footnote recommending using Do..Loop...

 

[gemma-the-husky]

i am just more used to a

while
---
end while

type of construct. it seems strange/unnecessary to me that you can add an extra do ... loop around this, so i never bother, as while/wend has served me on all occasions (I gather from this thread that it is now outdated - but the machinbe code it generates cant be any different surely?)

technically though the reason i use a

while
wend

rather than

repeat
until

is that if you test the condition at the top you don't have to process the block contents at all, but if you test it at the bottom, then you have to run it at least once once.

so

while not eof
process
wend

is more precise than
repeat
process
until eof

with the latter, you find yourself having to write extra tests before entering the loop, or doing some additional testing inside the loop, (or even just getting coding errors!)

 

[stopher]

i am just more used to a

while
---
end while

type of construct. it seems strange/unnecessary to me that you can add an extra do ... loop around this, so i never bother, as while/wend has served me on all occasions (I gather from this thread that it is now outdated - but the machinbe code it generates cant be any different surely?)

Access help says "The Do...Loop statement provides a more structured and flexible way to perform looping". There is also an Exit Do which is a more controlled way to exit the loop prematurely if needed. The Do loop appears to be more consistence with other MS languages. I agree though, use what you are more comfortable with providing it remains supported.

technically though the reason i use a

while
wend

rather than

repeat
until

is that if you test the condition at the top you don't have to process the block contents at all, but if you test it at the bottom, then you have to run it at least once once.

These two loop variants are designed to be used in different circumstances. You would use repeat..until (or Do ..Until) in a situation where you do want the code to run at least once e.g. you might be testing for a correct entry if a dialogue box. To use the While..wend in this circumstance would be slightly more contrived.

Chris

 

[gemma-the-husky]

stopher -

good point about the exit do - although i dont really like jumping out of loops - the termination condition should manage that, i feel.

to test for a dialogbox at the top of the loop is still easy - it just needs a "not" - although I agree you may need to be careful with the test to ensure it is false initially

while not acceptableinput
getinput
wend

is still not very different to

repeat
getinput
until acceptableinput

 

[sted69]

Using exit's and goto's isn't proper programming... There is always a way to nest the conditions in a way you won't need exits and goto's in most high level programming languages.

Exit- and Goto methods make your code hard to understand, especially when dealing with big programs.

As for me, there is no "legal" way to exit an IF structure unless its an "End If"

 

[Rabbie]

Using exit's and goto's isn't proper programming... There is always a way to nest the conditions in a way you won't need exits and goto's in most high level programming languages.

Exit- and Goto methods make your code hard to understand, especially when dealing with big programs.

As for me, there is no "legal" way to exit an IF structure unless its an "End If"

I quite agree. You should never need to use "Go to" in VBA except in an "On error".

Use of Gotos leads rapidly to "Spaghetti" coding that is virtually impossible to maintain.

 

[Banana]

Actually, if we just add meatballs and tomato sauce, it's not too bad. A spot of garlic bread and a glass of red wine helps as well.

 

[stopher]

Actually, if we just add meatballs and tomato sauce, it's not too bad. A spot of garlic bread and a glass of red wine helps as well.

And parmesan

I agree with the points about not using Goto and I've never felt compelled to use Exit Do either. Personally I stopped using Goto when I stopped using Fortran 77.

Chris

 

[Rabbie]

Actually, if we just add meatballs and tomato sauce, it's not too bad. A spot of garlic bread and a glass of red wine helps as well.

I find the tomato sauce can make the listings a bit difficult to read when i spill it and the red wine tends to lead to a series of syntax errors. can't think why