Try and Catch Statements

Try statements signify the start of a block of code that you want to control with
the X++ exception handling system. Any exceptions that are thrown in that block
of code can be caught and handled in the associated Catch statements.

Catch statements come after the Try statement and define what code is executed
when each exception is thrown. You do not have to define a Catch statement for
every possible exception. However, each Try statement must have at least one
Catch statement. It is also possible to define a Catch statement that is executed
for any exception type. Try statements can be made within the scope of other Try
statements. If a Catch statement is not defined for the exception being thrown by
an inner Try statement, the code will step out to the next outer Try statement to
attempt to find a matching Catch statement for the exception. This will continue
until a Catch statement is found, or there are no more outer Try statements.

Retry statements tell the system to go back to the Try statement and attempt to
execute the code again. Any data that is loaded before the Try statement will
remain as it is, but any data retrieved or modified after the Try statement will be
refreshed.

The following example has a Try statement, signifying the start of the exception
handling block of code. The code then tries to insert a new customer record.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

CustTable custTable; Counter retryCount; #define.RetryMax(5) try { custTable.AccountNum = "0001"; custTable.CustGroup = "50"; custTable.insert(); } catch (Exception::Error) { error("There was an error while inserting the record."); } catch (Exception::Deadlock) { if(retryCount < #retryMax) { retry; } }

There are then two catch statements. The first catches an error exception. The
error may be caused, for example, during the insert() method. The second catch
statement catches a deadlock exception. The database throws this exception when
it recognizes that a deadlock has occurred.
When a deadlock exception is thrown, all locks on tables that this process holds
are released. This could allow the other process or processes that are also
deadlocked to continue. By calling a retry, the process can attempt to update the
record again and may now be able to be completed. It is a best practice that a
retry uses a counter so that the number of retries can be controlled, and a user
does not become stuck in a loop.

Best Regards,
Hossein Karimi