Error handling for Data Object operations
- Last Updated: March 30, 2020
- 3 minute read
- OpenEdge
- Version 12.2
- Documentation
For any Data Object operation that completes with an error of any type, the
success property of the returned request object (and the
success parameter passed to any event or Promise
callback) is set to false. Error information from operation
execution can be found using two separate mechanisms:
- Calling the
getErrors( )method on a JSDO table reference to return associated errors from the most recent call tofill( )orsaveChanges( ). - Inspecting the
responseandxhrproperties of the request object for information on operation errors and on web application, web server, or network errors, respectively, from the most recent call tofill( ),saveChanges( ), or an invocation method.
Note that for a Data Object Create, Update, Delete (CUD), or for a Submit
operation (on a before-image resource only), if any error, at any point causes the operation
to complete unsuccessfully, by default (with the autoApplyChanges property set to true), the
record or records in JSDO memory are reverted prior to any changes that caused the operation
or operations to execute by invoking saveChanges( ), and the
intended record changes are preserved as values of appropriate request object properties.
For example, a failed Create operation causes the added record to be removed
from JSDO memory. The record object (or objects for Submit with before-imaging) that were
originally added for the operation are then available for your re-use as the value of the
jsrecord property (or for Submit with before-imaging, as
the value of the jsrecords property) of the request object
(or of the record parameter passed to the afterCreate event callback). A similar reversion occurs for the
Update and Delete operations (or updated and deleted records of a Submit with before-imaging),
with the field values of any updated record reverted to their original values, and any deleted
record added back to JSDO memory. The original updated or deleted record or records are
available using the appropriate jsrecord or jsrecords property of the request object.
getErrorString( ) method on the record
object.You can change this default behavior by setting the autoApplyChanges property to false. In this case,
when the operation completes you can accept or reject the record changes in JSDO memory using
one off the following methods:
acceptChanges( )acceptRowChanges( )rejectChanges( )rejectRowChanges( )
Note that when autoApplyChanges is true, corresponding errors returned from a call to saveChanges( ) are cleared from JSDO local memory (and also the
response and xhr properties of returned request objects)
at the following points, which ever comes first:
- Execution completes for the final callback subscribed to an operation event or registered
to the Promise object returned by
saveChanges( ). - A corresponding
accept*Changes( )orreject*Changes( )method is executed.
However, if you need access to errors from the most recent call to fill( ) or saveChanges( ) beyond
these points, you can return them for any associated JSDO table reference by calling getErrors( ), regardless of the setting of autoApplyChanges or the execution of accept*Changes( ) and reject*Changes( ) methods.
These errors are available for return until the next call to either fill( ) or saveChanges( ).