next »

[Tim B.]

I have mentioned this already to EMEA support, but perhaps someone could explain what the difference is between a normal error and a FORMS statement error, particularly why they can't be trapped (or if they can, how).

We get various FORMS statement errors (subscript out of range, cannot write to GUI, etc) and we are unable to trap them with either WHENEVER [ANY] ERROR or TRY/CATCH.

Tim

[Reuben B.]

Tim,

I don't think it is correct to generalise and say that  "FORMS statement error" can't be trapped.

For example ...

DISPLAY 1/0

... generates ...

FORMS statement error number -1202.
An attempt was made to divide by zero.

... which is trapped.  However there are some such as ...

FORMS statement error number -1320.
A function has not returned the correct number of values expected.

FORMS statement error number -1326.
An array variable has been referenced outside of its specified dimensions.

... which appear in the errorlog but aren't trapped and cause the program to stop.

I too would be curious to know if there is someone way to differentiate these type of exceptions.  If I was to guess I would say it is potentially unsafe to allow the program to continue executing.  i.e. if you continued after a -1320 exception, what sort of state would the argument stack be in?, could a -1326 exception corrupt the value of adjacent variable in memory.

[Tim B.]

It seems sensible that certain errors are terminal, eg "A function has not returned the correct number of values expected".  However, it would be extremely useful to trap others such as "An array variable has been referenced outside of its specified dimensions" and "Cannot write to GUI", so that appropriate action can be taken in the program.

In BDS there was an fglprofile entry to ignore array range errors (haven't checked if this is Genero).  This used suppress the error message but also hide all sorts of nasty bugs, and I think it used to overwrite/return the first element of the array if it was referenced out of range.  I think we're better off without this, but we also need to be able to trap the error (an others like it) to either correct it or call our own error handler.  I've suggested that a profile entry could control this behaviour and maintain Informix compatibility.

I don't quite see why some of these are classed as FORMS statement errors anyway, but that's a different (Informix) matter.