ON ERROR phrase
- Last Updated: August 24, 2023
- 3 minute read
- OpenEdge
- Version 12.2
- Documentation
The ON ERROR phrase is one of the ABL
constructs used for altering the default condition handling for ABL blocks. By default, when
an error occurs in a block, all the changes to persistent data (database fields) are undone.
If the block is a transaction block, undo variables and temp-table fields are also undone.
See Develop ABL Applications for more information on
transaction blocks. The ON ERROR phrase can be used to
modify the scope of UNDO processing, possibly widening it
to an outer block. In addition, if an error occurs, the ON
phrase gives you control over where execution continues.
In general, the AVM performs error handling using this precedence, from highest to lowest. The AVM only abides by one of these when a condition is raised:
- Statement
NO-ERRORoption CATCHblock- Block’s
ONphrase (explicit or implicit)
Due to this precedence, the ON phrase is ignored if a local
CATCH block handles the error.
Syntax
|
- label1
- The name of the block whose processing you want to undo. If you do not name a block with label1, the AVM undoes the processing of the current block.
- LEAVE [label2]
- Indicates that after undoing the processing of a block, the AVM leaves the block labeled label2. If you do not name a block, the AVM leaves the current block.
- NEXT [label2]
- Indicates that after undoing the processing of a block, the AVM
executes the next iteration of the block you name with label2. If you do not specify a label with the
NEXToption, the AVM executes the next iteration of the current block. - RETRY [label1]
- Indicates that after undoing the processing of a block, the AVM
repeats the same iteration of the block.
Because
RETRYin a block without user input results in an infinite loop, the AVM automatically checks for this possibility and converts aRETRYblock into aLEAVEblock, or aNEXTblock if it is an iterating block. This behavior is often referred to as infinite loop protection. - RETURN ...
- Returns to the calling routine, if there is one. The following table
describes various
RETURNoptions:Option Description return-value In procedures and VOID methods, this must be a CHARACTER string. The caller can use the RETURN-VALUEfunction to read the returned value. For user-defined functions, non-VOID methods and property getters, the value must match the specified return type.ERRORUndoes the current subtransaction, and raises ERRORin the caller. You cannot specifyERRORwithin a user-interface trigger block or a destructor.For user-defined functions see note below.
ERRORreturn-valueUndoes the current subtransaction, and raises ERRORin the caller. The CHARACTER string you provide is available to the caller in theRETURN-VALUEfunction. The AVM also creates anAppErrorobject and stores the return-value in theReturnValueproperty.For user-defined functions see note below.
ERRORerror-object-expressionUndoes the current subtransaction, and raises ERRORin the caller. The specified error object instance is thrown to the caller.For user-defined functions see note below.
NO-APPLYIn a user-interface trigger, prevents the AVM from performing the default behavior for the trigger event. Otherwise, the option is ignored. Note: UsingRETURN ERRORin a user-defined function sets the target variable of the function to the Unknown value (?) instead of raisingERRORin the caller. See ABL Error Handling for more detail. - THROW
- Use this directive to explicitly propagate an error to the enclosing block, if there is one, otherwise to the caller. You can learn more about throwing error objects in ABL Error Handling.
Examples
In r-onerr.p, if you enter a
Customer number and the FIND statement is unable to find a Customer with
that number, the AVM raises an error. If an error occurs, the ON ERROR
phrase tells the AVM to undo anything that was done in the current iteration and start the
next iteration. Thus, you see any invalid numbers you enter, and you can continue to the
next Customer number you want to enter.
r-onerr.p
|
In r-onErrorThrow01.p the block propagates an error
from a DO block up to the main procedure block. A CATCH
block on the main procedure block handles the error.
r-onErrorThrow01.p
|
Notes
- For callable blocks, including procedures, user-defined functions,
class-based methods, and property accessors use the
ROUTINE-LEVEL ON ERROR UNDO, THROWorBLOCK-LEVEL ON ERROR UNDO, THROWstatement, if you want anUNDO, THROWdirective.BLOCK-LEVEL ON ERROR UNDO, THROWis a superset ofROUTINE-LEVEL ON ERROR UNDO, THROWand applies to more block types. - Error objects can be thrown from an application server and handled by a
CATCHblock on an ABL client. To be throwable from an application server to an ABL client, user-defined error classes must be defined on both the server and client sides, and the classes must be defined asSERIALIZABLE. For the full list of restrictions on class-based objects that are passed between application server and client, see the Parameter passing syntax entry. For more information on error handling in general, see ABL Error Handling. - If a block does not have implicit error handling capabilities (for example, a simple
DOorDO WHILEblock) you can add theON ERROR(orON STOP) phrase to explicitly turn it into one with error handling. This allows you to use aCATCHstatement within the block to catch any error or stop conditions. If you don't add theON ERROR(orON STOP) phrase and try to use aCATCHwithin the block, you get a compiler error.
See also
BLOCK-LEVEL ON ERROR UNDO, THROW statement,ON ENDKEY phrase, ON QUIT phrase, ON STOP phrase, RETURN statement, RETURN-VALUE function, ROUTINE-LEVEL ON ERROR UNDO, THROW statement, UNDO statement