So, I was trapping errors in a fex and thought I could use:

-IF &FOCERRNUM NE 0 THEN EXIT;

The documentation seems to suggest this is possible, as it says:

quote:

-IF expression [THEN] GOTO label1; [ELSE GOTO label2;]
                                   [ELSE IF...;]
where:

label1...label2
Is a user-defined name of up to 12 characters that specifies the target
of the GOTO action.

Do not use embedded blanks or the name of any other Dialogue Manager command
except -QUIT or -EXIT. Do not use words that can be confused with functions,
arithmetic or logical operations, and so on.

But alas, the result is:

 -IF 0 NE 1 THEN EXIT;
 0 ERROR AT OR NEAR LINE      1  IN PROCEDURE ADHOCRQ FOCEXEC *
 (FOC305) SPECIFIED LABEL NOT FOUND: EXIT

The 12 character limit is bad enough, but you can't even call EXIT or QUIT directly from an IF statement? That is embarrassing! Hasn't this language evolved at all since its inception?

Call me frustrated if you like, stuff like this does that to people. I'm at least very disappointed...

I wonder, is it possible to have focexec's pass through another parser first? Without significantly having to change our reports? I'm tempted to write my own parser for DM code, although I probably lack time to do that.

Wow, this would be the least of my worries, if I was worried about this.

This can be resolved by one extra line of code:

-IF &FOCERRNUM NE 0 THEN GOTO FEXIT;

...

-FEXIT
-EXIT

Hmmm, I think I saw this being used once:

-IF &FOCERRNUM NE 0 THEN GOTO EXIT;

...

-EXIT

As -EXIT actually has the pattern of a label, it worked!!!

Yes it does work, I use it quite often in testing.

-EXIT is a label and an action, you only need to have the -EXIT somewhere in the fex for it to be found.

But, if you have an error, do you just want to exit the program, or handle the error ?

Oh, a solution is not hard to figure out, it's just the way it works that's kind of ridiculous.

It gets even more interesting:

-SET &ECHO = ALL;
-IF 1 NE 0 THEN EXIT;
-TYPE One equals zero, really!
-EXIT
-TYPE We did not exit!

Which outputs:

quote:

 -IF 1 NE 0 THEN EXIT;
 -EXIT

So the parser is too lazy to realise that EXIT in a conditional statement has a meaning other than a GOTO label, yet it happily interprets a label of that same name as a command, even though it was used as a label!

The 12 character label limit has been raised to 64 characters in 7.7.

The documentation does not seem to suggest that you can do anything other than GOTO in a -IF at all. This is called Conditional Branching, which does exactly as its name suggests, branches. If you specify EXIT or QUIT, and there is an -EXIT or -QUIT in the program, then that is where control will go, NOT what it will do. Documentation is clear. DM is not trying to be anything other than a simple flow control language.

quote:

Documentation is clear.

Is it though?
It mentions that EXIT and QUIT can be used as labels, whereas other keywords cannot.

It does not mention at all what happens if you do use those keywords in that position. That's left to the interpretation of the reader.

My interpretation was that it would perform those statements, instead of branching to a label. That would make sense.

In practice, it requires those statements as a (bogus) label, but it does not just jump to that label, it steps back and re-evaluates the label as a statement! That is a pretty unusual program flow.

Usually programs continue executing after the label they branched to. They don't go back to re-interpret the label - the program counter is already past that position, after all.


Another problem with this mixing up of labels and statements is when a program has multiple -EXIT statements. If a conditional statement has to jump to such an EXIT label, there are multiple candidates. Which is it going to jump to?

Since -EXIT (whether used as a label or as a statement) will end the program flow, that's not a problem for that particular label, but by consequence it means that it is now acceptable to have duplicate labels!
Especially in combination with -INCLUDE to re-use existing code, that leaves room for some unpleasant flow control problems, where the flow jumps to a different label than the one the developer intended.


I wonder what the people at the language design chair at the local university will think of this. I'm fairly certain they'll find this humorous.

quote:

language design chair at the local university

Are you sure these still exist? Aren't they all playing with their GUIs and iPads these days?

You just need to add the label -EXIT to your focexec and the if statement will work.
TABLE FILE CAR PRINT CAR
END
-IF &FOCERRNUM GT 0 THEN EXIT;
-AAA
-TYPE GOOD STUFF
-EXIT

The documentation is clear. The GOTO is required. I'm not seeing anything in the documentation that implies that the GOTO is optional.

The fact that WebFOCUS is not kicking out a syntax error when you neglect to put in a GOTO is something worth complaining about, but you cannot object to the fact that unsupported syntax is not behaving the way you would expect it.

-IF (1 EQ 0) THEN GOTO EXIT ;
-TYPE 1 is NE 0
-IF (1 EQ 1) THEN GOTO EXIT ;
-TYPE This should not be typed

-EXIT

  

EricH

Documentation say it can be used as label not that it will act like label.

It is command, very clear, so use -EXIT and/or -QUIT and WF do just that.

Kofi

I think you can create a request for the documentation to be updated indicating that the "GOTO" keyword is optional as that is the only valid action in an -IF statement anyway.

Other than that, Dialogue Manager is what it is and I hope they won't change the way -IF has been implemented. Their code tightening caused sufficient rework during our latest upgrade from 5.3.4 to 7.7.03 and I can't imagine if they suddenly decide to enforce what the documentation say and require GOTO to always be used in -IF. I can see how many procedures would stop working, and not only at my place.

Yeah, yeah, one should always follow "good coding practices" and that's something I stand for, but we eventually slip on that a few times (perhaps inadvertently) not to mention the amounts of code written years and years ago and that still have to be maintained.

This message has been edited. Last edited by: njsden,

quote:

slip on that a few times

Wash your hands.

quote:

Another problem with this mixing up of labels and statements is when a program has multiple -EXIT statements. If a conditional statement has to jump to such an EXIT label, there are multiple candidates. Which is it going to jump to?

DM will read down the code for the label, unless that label has been encountered previously, when the flow will proceed to the previously encountered label. If the label has not been encountered by the end of that focexec, the search will proceed from the top of the procedure. If the label has not been found at the point the GOTO was evaluated an error will be produced. So a search for -EXIT or -QUIT will always search forward, then from the top, because there can be no previously encountered -EXIT or -QUIT as the process would have finished at that point. All of this is in the documentation.

quote:

Since -EXIT (whether used as a label or as a statement) will end the program flow, that's not a problem for that particular label, but by consequence it means that it is now acceptable to have duplicate labels!
Especially in combination with -INCLUDE to re-use existing code, that leaves room for some unpleasant flow control problems, where the flow jumps to a different label than the one the developer intended.

Duplicate labels are not a problem as far as DM is concerned, and never have been. DM doesn't care. However you should as you loose control. That's just plain bad coding. However, remember that you cannot navigate into, or out of, a -INCLUDED focexec, so duplicate labels within different -INCLUDE files are not, and never have been a problem. Just bad practice perhaps...

Careful, dupe DM labels can cause program looping, depending on location in code, and compounding the brain damage, if you have ECHO and/or tracing turned on, you will fill up your disk...before you know it, you've got a real mess on your hands (been there and done that, too ). Golden rule of thumb: NEVER have dupe DM labels in your code. That also means you should code only one -EXIT or -QUIT.

Recent code tightening seems to generate a message about duplicate labels...

I personally think DM is cool.

So yeah, I say PEBKAC.

.
.
.

(Problem Exists Between Keyboard And Chair)

quote:

Originally posted by Alan B:
Duplicate labels are not a problem as far as DM is concerned, and never have been. DM doesn't care.

That's the problem. It's far too easy to create an unintended infinite loop in DM.

The fact that you have to hand-code loops using labels and exit conditions at just the right locations doesn't help either - a mistake is easily made, the language does nothing to protect you against that.

There is a long-running ticket to add block-level statements to DM, so that you can for example execute a block of FOCUS code conditionally. Maybe, just maybe, they're going to implement that some time. Until then, you need to jump around using GOTO's.
Being able to EXIT or QUIT without having to jump to a bogus -EXIT or -QUIT label would be a nice addition to that feature and hardly difficult to implement.

quote:

Originally posted by Anatess:
I personally think DM is cool.

There is nothing cool about DM. It's like calling a cave painting modern art.

Without joining the cave-painting vs. modern art argument there's a simple answer:
1) Never use EXIT as a label
2) Always use GOTO in the IF statement

Personally I always just put

 -DONE 

at the end of every FEX and GOTO that .....

Hi Wep5622,

Suggestion from our FocWizards:
Since it SPECIFICALLY states in the doc, that the syntax of an ‘-IF…THEN’ expression needs a ‘GOTO’:

-IF expression [THEN] GOTO label1; [ELSE GOTO label2;]

And that the target must be a label, if you coded ‘-EXIT’ in your procedure, it would work. Without it, the GOTO doesn’t know WHERE to go (as the error message says).

Additional info:
A - in column 1 of a FOCEXEC indicates it is Dialogue Manager.
Focus looks at the next word. If it is a known Dialogue Manager command, then that command is processed, and it is treated as a label as well for parsing. If it is NOT a known command, then it is obviously only as a label. EXIT is a Dialogue Manager command, as is RUN , QUIT, and IF.
So, -EXIT at the beginning of a line will automatically exit. GOTO EXIT will find it as a label, and then process the command.

However, -IF is its own command, which is of the form -IF expression [then] GOTO label.

not IF expression [THEN] dialogue manager command.

Because of that, and realizing that some folks would forget to code the GOTO, FOCUS actually puts it in for you , hence the error message.

Hope this helps.


Cheers,

Kerry

George, great minds...

We also have a label at the end of all our prgrams, ours is -PGM_END

I believe that the fex should not just stop at a point in the program, unless you are testing of course, but should gracefully finish at the end of the fex. This way if it is included control passes back to the calling pgm, and so on.

I once surprised my colleagues, when they opened up one of my fexes in DS in the Logical View tab, and the program started from a single point also and ended at a single point, with many branches in between.

I guess this is takeing care of loose ends.

Waz/George, I totally agree. I think it's something we seasoned Focus/WebFocus programmers do, putting in a named 'END' label as the last statement in our fexes so that the program finish occurs natually. In a "Best Practice" world, -EXIT should only be used for testing. If I recall, there is (or used to be) a problem with -EXIT and Report Caster so for that and other reasons mentioned I never have it in a production report.

This message has been edited. Last edited by: DavSmith,

Agreed.

I also remember something similar about Report Caster.

quote:

Originally posted by Wep5622:

quote:

Originally posted by Anatess:
I personally think DM is cool.

There is nothing cool about DM. It's like calling a cave painting modern art.

I'd say it's like getting frustrated over the microwave oven because when you bake your thanksgiving turkey with it, it comes out hard as a rock.

DM is not "object-oriented programming". It's top-down action and I always give top-down programs with one exit point in the code as a standard. Somewhere in the bottom of all my fexes is a label called -:ENDFEX and the line immediately after it has -EXIT.

Sometimes, I write code after the -EXIT but it doesn't get executed unless I specifically branch down to it. I sometimes write my error handling routines after the -EXIT just to separate them from the main code and it always has GOTO :ENDFEX so it still exits out of one place.

So, if I want to exit out of the code, I GOTO :ENDFEX instead of GOTO EXIT because I don't treat -EXIT as a label (even if it can be GOTO'd), instead, I treat it as the End of Line command... okay, I'm an 80's-Tron fan. LOL!

quote:

I'm an 80's-Tron fan. LOL!

And nothing wrong with it (maybe because I'm one myself ).

I also find Dialogue Manager cool. I just have to keep it within the context for which it was designed. To me, DM is not a programming language but a "macro" language, some pre-processing stuff that happens before the actual code (TABLE FILE blah) gets executed. When I see it from that perspective and compare it with other macro languages out there, DM is very powerful and functional.

Would I like it to do more stuff? sure!! but I have to make the best I can out of what it provides and so far it has not failed me except for a few ugly infinite loops I used to get whenever there was a syntax error in my code, combined with a -EXIT somewhere and &ECHO=ON

That's now history as we moved to 7.7 a couple of months ago and that behaviour disappeared.

quote:

"macro" language, some pre-processing

Use it for what it was intended for, and ask for new features.