If/Else Madness << Back

Use UI

Function Func0 Returns Boolean
	If (FALSE) Showln "Then Clause"
End_Function

Function Func1 Returns Boolean
	If (True) Begin
	End
	Else Begin
	End
	Else Showln "Else Clause"
End_Function

Boolean b
Get Func0 to b
InKey b

Case 1: Double Else
In the code above, "Func1" has an extra "Else" statement. Note that code inside "Func1" should never been executed, and yet the words "Else Clause" will show up in the output window. That indicates that the ELSE statement can show up ANYWHERE in the code as long as there is a IF statement above (could be way way above)

IF (bSomeCondition)
    Send SomeMessage
    Send SomeOtherMessage
Else Send OtherMessage

Case 2: No Begin End, No problem (Extension to Case 1)
If you look into FMAC, you will realize that the "IF" statement is just a JNE/JE statement (Assembly). In this scenario, according to the language guide, you are supposed to put "Begin/End" after the "IF" statement because you want to execute that two lines of code if the condition is met. In this example, you can get away with not using "Begin/End"

IF (bSomeCondition) Begin
    Send SomeMessage
End
Send SomeOtherMessage
Else Send OtherMessage

Case 3: Random Lines (Extension to Case 1)
Since the "Else" statement can show up pretty much everywhere, why not add some random lines in between If/Else since the compiler seems to be totally fine with it. The "Send SomeOtherMessage" will behave like if it is inside the Begin/End block.

Use UI

Function Func0 Returns Boolean
	If (FALSE) Showln "Then Clause"
End_Function

Class SomeClass is a cObject
	Function Func1 Returns Boolean
		If (True) Begin
		End
		Else Begin
		End
		Else Showln "Else Clause" // I am in a different class!
	End_Function
End_Class

Boolean b
Get Func0 to b
InKey b

Case 4: Instantiation is for the weak (Extension to Case 1)
"Else" is so powerful that it breaks Class boundaries. In this case we never instantiated "SomeClass", and yet we can jump straight to it (You shall see the line "Else Clause" in the output window) It almost seems like "IF/ELSE" in VDF is just a poorly hacked together version of GOTO statements.

Conclusion:
The compiler should have caught all the above unintended errors. I have verified that the bug still exists in DF 19.