Using Try Functions in Navision 2016

You may have seen in different programing language concept of try… catch…

The try-catch statement consists of a try block followed by one or more catch clauses, which specify handlers for different exceptions.

When an exception is thrown, the language looks for the catch statement that handles this exception. If the currently executing method does not contain such a catch block, the language looks at the method that called the current method, and so on up the call stack. If no catch block is found, then the language displays an unhandled exception message to the user and stops execution of the program.

The try block contains the guarded code that may cause the exception. The block is executed until an exception is thrown or it is completed successfully.

Although the catch clause can be used without arguments to catch any type of exception, this usage is not recommended. In general, you should only catch those exceptions that you know how to recover from.

A throw statement can be used in a catch block to re-throw the exception that is caught by the catch statement.

You can also re-throw an exception when a specified condition is true.

Now Dynamics Navision 2016 introduces this concept in C/AL in terms of function.

Try functions in C/AL enable you to handle errors that occur in the application during code execution.

For example, with try functions, you can provide more user-friendly error messages to the end user than those thrown by the system.

You can use try functions to catch errors/exceptions that are thrown by Microsoft Dynamics NAV or exceptions that are thrown during .NET Framework interoperability operations.

Try functions catch errors similar to a conditional Codeunit.Run function call, except with the following differences:

Try function calls do not require that write transactions are committed to the database.
Changes to the database that are made with a try function are not rolled back.

Creating a Try Function

To create a try function, add a function in C/AL code of an object (such as a codeunit) as usual, and then set the TryFunction Property property to Yes. A try function has the following restrictions:

In test and upgrade codeunits, you can only use a try function on a normal function type, as defined by the FunctionType Property (Test Codeunits) or FunctionType Property (Upgrade Codeunits).
The try function cannot have a user-defined return value.
Understanding Try Function Behavior and Usage

A function that is designated as a try function has a Boolean return value (true or false). A try function has the construction OK:= MyTryFunction.

If a try function call does not use the return value, the try function operates like an ordinary function and errors are exposed as usual.

If a try function call uses the return value in an OK:= statement or a conditional statement such as IF-THEN, errors are caught.

You can use the GETLASTERRORTEXT Function to obtain errors that are generated by Microsoft Dynamics NAV.

To get details of exceptions that are generated by .NET Framework objects, you can use the GETLASTERROROBJECT Function to inspect the Expection.InnerException property. You can see codeunit 1291 - DotNet Exception Handler.

If you call the GETLASTERRORTEXT function immediately after you call the CLEARLASTERROR function, then an empty string is returned.

The result of the GETLASTERRORCODE Function is not translated into the local language. The result of the GETLASTERRORTEXT function is translated into the local language.

TryFunction usage concept you can find throughout the system especially for Posting Preview, Applying Entries, and Printing Reports etc. in several codeunits.

However to give simple sight on usage of same I am using my below defined example.

I have created a codeunit with TryFunction to add an Item to Item Table.


I created another codeunit with function which calls the above codeunits AddItem function passing parameter to function. Testing it if it is successful or any error occurred while performing the action. 

When I execute the second codeunit in first run it says successful as Item dosen’t exists in the table. When I execute for second time it gives error as the item was already added to the table in its first run.


Above example also demonstrates the usage of ClearLastError, GetLastErrorCode and GetLastErrorText functions.

Spend some time in scanning other codeunits for better understanding about TryFunctions.

You can see the example provided by Microsoft MSDN also to understand usage of TryFunction.

The following example illustrates the use of a try function together with codeunit 1291 DotNet Exception Handler to handle .NET Framework Interoperability exceptions. The code is in text file format and has been simplified for illustration. The CallTryPostingDotNet function runs the try function TryPostSomething in a conditional statement to catch .NET Framework Interoperability exceptions. Errors other than IndexOutOfRangeException type are re-thrown.

[TryFunction]

PROCEDURE TryPosting@1);

BEGIN

CODEUNIT.RUN(CODEUNIT::"Purch.-Post");

END;

PROCEDURE CallTryPostingDotNet @2();

VAR

MyPostingCodeunit@1 : Codeunit 90;

MyDotNetExceptionHandler@2 : Codeunit 1291;

IndexOutOfRangeException@3 : DotNet 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.System.IndexOutOfRangeException'

BEGIN

IF TryPostSomething THEN

MESSAGE('Posting succeeded.')

ELSE BEGIN

MyDotNetExceptionHandler.Collect;

IF MyDotNetExceptionHandler.TryCastToType(IndexOutOfRangeException) THEN

MESSAGE('The index used to find the value was not valid.')

ELSE

MyDotNetExceptionHandler.Rethrow;

END;

END;

I will come up with more details in my upcoming posts.