Automatic Updates and Exception Handling

If an exception occurs during an automatic update (for example, inverse maintenance, automatic key maintenance, or parent‑child deletion), the transaction is aborted when returning from the first exception handler. The transaction is aborted because allowing the transaction to be committed could result in updating one side of a relationship (the property or collection whose update initiated the automatic update) but not updating the other side (because that operation encountered an exception). This could result in a loss of logical integrity caused by corrupt inverses or dictionary keys.

While the exception handler is executing, you are still in transaction state and objects created or updated in the transaction are still visible. Any attempt to commit the current transaction in your exception handler raises an exception 1252 (Transaction must be aborted). If you abort the current transaction in the exception handler, which is often a good idea, you can then begin and commit new transactions.

The aborting of a transaction when an automatic update cannot be completed may affect the way you choose to code a task. For example, if you create a large number of objects in a single transaction, an automatic update exception (for example, 1310 (Key already used in this dictionary)) can be raised if the objects are being added to a dictionary as part of the automatic inverse maintenance.

Aborting the transaction results in all previously created objects being lost. In such situations, you may choose to check for the existence of a duplicate key by calling the Dictionary class includesKey method rather than using an exception handler to deal with any duplicates.