[CLOSED] how to trap an error in an included fex

Hi

I have posted about this before but I am still looking at it.

Say I have a fex that has a bug in it.

like this

-*with_bug.fex
-GOTO MISSING_LABEL;

that's it. there is no missing_label so it throws
(FOC305) SPECIFIED LABEL NOT FOUND: MISSING_LABEL

OK that's fine.

Now say I have a second fex that contains this line in it.

-INCLUDE with_bug.fex
-TYPE whatever
-TYPE &FOCERRNUM
When I run this I get
(FOC305) SPECIFIED LABEL NOT FOUND: MISSING_LABEL

I do not get the focerrnum or the "whatever" text. The processing stops in the included file and that is all I am out of luck.

Is there any way to trap that error? Like on error resume next kind of thing. try .. catch?

Note: I am not looking for advice as to how to avoid the error. I need to call an external fex (which is outside of my control) and the fex could have an error in it.

If there is an error in it then I want to branch somewhere and do a clean display for the user with a nice error message.

How can I trap that error inside the calling fex?

Thanks

Jodye

This message has been edited. Last edited by: <Kathryn Henning>,

WF 8.0.0.5M

Posts: 246 | Location: Montreal, QC, Canada | Registered: October 01, 2003

Francis Mariani

Expert

posted

Hide Post

As far as I know, only non-Dialogue Manager errors can be tested for with &FOCERRNUM, which is too bad.

I hope someone has better news.

Francis

Give me code, or give me retirement. In FOCUS since 1991

Production: WF 7.7.05M, Dev Studio, BID, MRE, WebSphere, DB2 / Test: WF 8.1.05M, App Studio, BI Portal, Report Caster, jQuery, HighCharts, Apache Tomcat, MS SQL Server

Posts: 10577 | Location: Toronto, Ontario, Canada | Registered: April 27, 2005

Ignored post by Francis Mariani posted

Show Post

j.gross

Virtuoso

posted

Hide Post

Counterexample:

-SET &ECHO=ON;
-SET &FOCERRNUM=-1;
TABLE FILE NONESUCH
LIST *
END
-RUN
-? &FOCERRNUM

shows
&FOCERRNUM = 205

Posts: 1925 | Location: NYC | In FOCUS since 1983 | Registered: January 11, 2005

Ignored post by j.gross posted

Show Post

Francis Mariani

Expert

posted

Hide Post

quote:
SET &ECHO=ON;
-SET &FOCERRNUM=-1;
TABLE FILE NONESUCH
LIST *
END
-RUN
-? &FOCERRNUM

Is this trapping a Dialogue manager error?

When I run the code, I get:

-SET &FOCERRNUM=-1;
 TABLE FILE NONESUCH
 LIST *
 END
 -RUN
 0 ERROR AT OR NEAR LINE      3  IN PROCEDURE ssearch_drill_holdings
 (FOC205) THE DESCRIPTION CANNOT BE FOUND FOR FILE NAMED: NONESUCH
 BYPASSING TO END OF COMMAND
 CURRENTLY DEFINED & VARIABLES STARTING WITH 'FOCERRNUM':
 &FOCERRNUM    = 0
 -? &FOCERRNUM

Francis

Give me code, or give me retirement. In FOCUS since 1991

Production: WF 7.7.05M, Dev Studio, BID, MRE, WebSphere, DB2 / Test: WF 8.1.05M, App Studio, BI Portal, Report Caster, jQuery, HighCharts, Apache Tomcat, MS SQL Server

Posts: 10577 | Location: Toronto, Ontario, Canada | Registered: April 27, 2005

Ignored post by Francis Mariani posted

Show Post

j.gross

Virtuoso

posted

Hide Post

Looks like in new feature in 8.x

I can't see why &FOCERRNUM shouldn't run along the lines of &LINES, making attributes of the outcome of FOCUS COMMANDs accessible for decisionmaking in Dialog Manager.

Posts: 1925 | Location: NYC | In FOCUS since 1983 | Registered: January 11, 2005

Ignored post by j.gross posted

Show Post

jodye

Platinum Member

posted

Hide Post

Like Francis says... the problem is that it seems to be impossible to catch a DM error. Processing just halts.

assume CAUSE_ERROR is not in the fex....

-GOTO CAUSE_ERROR
-TYPE AAA

(FOC305) SPECIFIED LABEL NOT FOUND: CAUSE_ERROR

I do not get the AAA. There is no way to handle that error as far as I can see.

Thanks

Jodye

WF 8.0.0.5M

Posts: 246 | Location: Montreal, QC, Canada | Registered: October 01, 2003

Ignored post by jodye posted

Show Post

susannah

Expert

posted

Hide Post

i'm thinking that some focerrnums are ebola, and some are just the flu.
if you have no control over the included fex, and it has a fatal error, its going to flat die on you. period.
it seems that GOTO labelname is going to be fatal if that labelname doesn't exist, whereas TABLE FILE fantasyfile appears to be nonfatal, as it offers the option 'BYPASSING TO END OF COMMAND'