Is there a statement that could be put at the top of a program to 'branch on any error' to an ErrorRoutine that could then handle whatever happened ?

I can do most of this with specific tests and branches, but that requires anticipating the errors in advance, which is sometimes possible.

I want to trap things that may get past my tests and terminate a little more elegantly.

This programmer-defined ErrorRoutine procedure would ideally handle the problem, maybe fix it, and send the program back to try again.

I've tried ERROROUT but that just gives a message and bails out.

Any ideas ?

Thanks in advance,
Charlie

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

Sounds like you want a try {} catch {} type code.

This doesn't exist as far as I know.

MY suggestion is after any piece of code check &FOCERRNUM and if it is not 0, or one of the warning codes, then process the error. Just make sure you put a -RUN before the test.

Thanks Waz,

I was hoping not to have to put a lot of extra code in there any more than I have to.

WebFOCUS doesn't throw error codes that the code can 'catch, I take it ?

You're right though, I want to 'catch' errors on the fly, and not have to keep looking for them with a lot of code.

I'll 'INCLUDE RUNerrorCheck' whenever I think there might be a problem :

Filename: RUNerrorCheck
------------------------
IF &FOCERRNUM NE 0 THEN GOTO ErrorCheck ELSE
-RUN
------------------------

...and put my checks at the end.

Is there a way to 'RESUME' from the point where the error occurred to recover ?

Thanks,

Charles,

If you are including a fex for error checking, keep in mind that you cannot GOTO a label outside the INCLUDE.

In answer to your second question, there is no resume functionality. There is so much functionality that could be completely dependent on what previously may (or may not) have occurred that it ouwld never know whether or not it was safe to continue. For example, a specific piece of code that creates a hold file errors out. If that hold file is subsequently used, it cannot continue because the hold file does not exist.

I can see why this would be desirable , but given the way WF/FOCUS works, I believe there would be more occasion where a resume would not be possible than those where it could continue without further effect. Based on your Dialogue manager code and evaluation of &FOCERRNUM, you could manually overcome this - the key word being MANUALLY.

Darin,

Interesting that I can't INCLUDE a target label in another file.

I had thought INCLUDEd code was simply inserted into the body 'as is'.

I've tried (just for fun) INCLUDE-ing the ON TABLE HOLD part of a TABLE FILE request in a separate file and it worked fine.
(Why anyone would want to do this, I don't know, but it worked fine !)

I'd think the label someplace else would not be a problem either, but it apparently is.
Kinda puts the kebosh on what I was going to do.

Thanks for the insight !

Charlie

Charlie, We use INCLUDEs here quite alot and one of them is the piece of code that has the ON TABLE HOLD, or in our case the last ON TABLE HOLD. This INCLUDE handles the output format and whether the report is returned to the screen or written somewhere.

As for the Error Checking, we will check the FOCERRNUM after each include/logical section of code for errors, and go to a section of the report that handles the error.