Kbase P99765: ERROR-STATUS:ERROR Is Not Always Set By ASSIGN NO-ERROR
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
21/01/2005 |
|
Status: Unverified
SYMPTOM(s):
ERROR-STATUS:ERROR Is Not Always Set By ASSIGN NO-ERROR
CAUSE:
Sometimes it appears that the ERROR attribute of the ERROR-STATUS System Handle is not set as it should be when using the NO-ERROR
option in an ASSIGN statement, whereas messages are appended to the GET-MESSAGE() stack. This problem has been especially apparent when assigning widget or object attributes. For instance, with a List-Item-Pairs Combo-Box called CB, if one does:
CB:LIST-ITEM-PAIRS = "Only one item!" NO-ERROR.
Then the ERROR-STATUS:ERROR will remain set to false and one will not receive error messages 7452 and 4058. They are, however, available
with ERROR-STATUS:GET-MESSAGE(1 and 2).
The ERROR-STATUS:ERROR is not set whenever an error message is generated. Rather, it is set only when the error-condition is raised.
The error-condition is raised only for more serious errors; many of which involve database errors (or UNDO variables), or a RETURN ERROR from a procedure. When an error-condition is raised, and there is no NO-ERROR on the statement, that is when all the block-level Undo and Retry processing happens.
The syntax error shown with List-Item-Pairs above is not the sort of error that an error-condition would be raised for.
Also, it is not possible to enumerate the cases where NO-ERROR will fail to set ERROR-STATUS, or where it will fail to suppress error-messages, and likewise for when it does set them from within an expression. These are cases that come up ad-hoc, sometimes from third parties and sometimes from unusual transaction conditions and cannot be documented or even predicted exhaustively. If someone wants a one-size-fits all, then a solution is to test if ERROR-STATUS:NUM-MESSAGES > 0.
FIX:
There are a few possible ways to deal with this. If one really need to know whether an error occurred or not, one can try these methods:
If the application has the message area showing, add the code SESSION:SYSTEM-ALERT-BOXES = NO. Then remove the NO-ERROR from the statement. Now, when the statement executes, the errors will appear in the message area. Or, if Alert-Boxes are acceptable, then just remove the NO-ERROR syntax.
The best option might be to use methods to manage the widgets or objects. These all return a logical value showing whether they were successful or not. Just query the logical variable and proceed accordingly.
Example -- if one has a logical variable called MthRtn and this syntax:
MthRtn = DecimalComboBox:ADD-LAST("One item makes problem") NO-ERROR.
Then MthRtn will be set to NO as desired, and ERROR-STATUS:ERROR will still be set to NO.
As explained in the cause Statement, it is also possible to rely on ERROR-STATUS:NUM-MESSAGES > 0 instead of ERROR-STATUS:ERROR. Now, if one finds out that ERROR-STATUS:ERROR is set during the tests, then he can safely rely on it.