Running code under the debugger, I found that the program line pointer went to the line past the END of the sourcecode in the following case:

LABEL:

If (condition) Then

 Statement 1

 Statement 2

RETURN

END

Notice that the code contains an error – the "If" statement is missing its "End." Since this error causes program execution to go to the end of the source before executing the RETURN, I thought I would place a DEBUG statement there. Then I would be able to trap for this type of programming error during testing. Otherwise, this error can only be caught when stepping through the code in the debugger.

Well, the compiler does not allow a debugger statement at the end of the code, after the final END. So it looks like the code execution is doing something wrong, and I can see this, but the compiler and debugger statement placement cannot trap for this error. Any comments from the authorities?

I see nothing wrong here. The if statement is not missing and End it exists after the return. ????

John,

I understand that an END exists. As a holdover from AREV, I usually put a final END at the bottom of every routine. However, in this case another END should have preceded the RETURN. That was definitely a programming error. You can't see this in the posting, as the web interface does not show the indentation which I did attempt to insert.

In execution the program pointer moves to the (non-existent) line following the final END. I wanted to put a debug there to trap for such errors, but the compile prohibits that. So, the compiler and the program interpreter disagree on whether a program line position exists after the "final END."

The compiler generally ignores indention.

pre.code {

 background-color: #E5E5E5;

 border: 1px solid #000000;

 width: 450px;

 padding: 5px;

 font-family: courier, verdana, arial, serif;

 margin: 0px 10px auto;

}

subroutine eraseme( void )

null

label:
if 0 then
   null
   null
   return
end

debug

This compiles and runs. Since there's not a proper termination, the compiler puts one in. Since it's not in the source code, it doesn't display, the same as other source that doesn't exist doesn't display, like the function headers of event code.

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

My experience was that my code, which was just slightly more complex than your example, would not compile because the debug statement followed the final end. Compilation required removing the debug statement. Maybe we just have to disagree about what the compiler can do.

My experience was that my code, which demonstrated the problem you are questioning, would compile even with the debug statement followed the final end. Compilation did not require removing the debug statement.

There is no reason to disagree about what the compiler can do. It can only do what it can do. It is a program. It should, given a set of conditions, the same time, time and time again. That's what software does.

We have shown you that the compiler will process after a final end statement. Therefore, there is not a problem with the compiler, and your code is in error.

Also, just for the record, we did test this by putting a debug at the end of more complicated code. We didn't see the need to post 48K of source code when a small example should have sufficed.

If we had this problem, we'd run our source through a syntax checker, or at least a program formatter, to ensure there were not any missing END or RETURN statements.

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

I'm sorry. You are saying that because your code example did not produce the same results as mine, my observations about the compiler and subsequent execution must be wrong. It is about this assumption on your part that we disagree.

View this thread on the Works forum...