Enhanced Error Management in 4D Code

Throwing errors in your 4D code is now possible starting from v20R2.

Those errors behave as any 4D error: they trigger an error dialog or can be handled in an ON ERR CALL method.

This feature will ease your life because you’ll be able to improve the quality of your code by proactively detecting errors as soon as they occur. You can also handle better error logging.

Before digging into details, It’s important to note that this feature is the first step towards achieving robust error management.

Now, let’s dig into the details!

This feature relies on a new throw command. This command can be used differently, detailed below and in the HDI.

HDI_THROW_ERRORS 

How to Throw and handle errors

The errors thrown with the throw command behave as any other 4D error. No ON ERR CALL method has been set up in the example below.

An error is thrown with a code and a description, triggering an error dialog.

throw(1; "This is an error")

In this other example, an ON ERR CALL method has been set up, and the thrown error can be got with the Last errors command.

ON ERR CALL("handleErrors")
throw(1; "This is an error")

 

blank

 

The throw command in details

This new command can be called in different ways according to your needs.

Throw predefined errors.

You can raise predefined errors set up in your project XLF files. For this, pass an object as a parameter to the throw command. This object must contain the properties:

  • componentSignature: the component code raising the error
  • errCode: the error code

 

An error message matching the resname ERR_componentSignature_errCode is searched in the XLF files of your project, and the error is thrown.

The error message can use dynamic placeholder values. In your XLF file, specify the placeholder name into braces {}. Then in the error object, add a property whose name is the placeholder name and provide its value.

Example:

var $file : 4D.File

ON ERR CALL("handleError")

$file:=File("/PROJECT/HDI file")

If (Not($file.exists))
	throw({componentSignature: "HDI1"; errCode: 1; name: "HDI file"; path: "/Project"})
End if 

Here is a sample of the French-translated Errors.xlf file:

<trans-unit id="1" resname="ERR_HDI1_1">
<source>The file &quot;{name}&quot; is not found in {path}.</source>
<target>Le fichier &quot;{name}&quot; est introuvable dans {path}.</target>
</trans-unit>

The ON ERR CALL method can proceed with the error:

blank

 

Use the deferred mode

Using the boolean property deferred in the object parameter allows you to stack thrown errors and proceed with them globally later. In the method below, the ON ERR CALL method is called at the end of the current method execution. Its proceeds with the stacked errors returned by the Last errors command.

var $file : 4D.File

ON ERR CALL("handleError")

$file:=File("/PROJECT/HDI file")

If (Not($file.exists))
	throw({componentSignature: "HDI1"; errCode: 1; name: "HDI file"; path: "/Project"; deferred: True})
	throw({componentSignature: "HDI1"; errCode: 2; name: "HDI file"; path: "/Project"; deferred: True})
End if 

Here is a sample of the French-translated Errors.xlf file:

 <trans-unit id="1" resname="ERR_HDI1_1">
<source>The file &quot;{name}&quot; is not found in {path}.</source>
<target>Le fichier &quot;{name}&quot; est introuvable dans {path}.</target>
</trans-unit>
<trans-unit id="2" resname="ERR_HDI1_2">
<source>Try another file name</source>
<target>Essayez avec un autre fichier</target>
</trans-unit>

The handleErrors method is called once and can get the stacked errors thanks to the Last errors command:

blank

A variation of the deferred mode is to call the throw command without parameters. This is useful in an ON ERR CALL method.

It stacks the current errors until the current method ends. Then the ON ERR CALL method is called to proceed with the stacked errors.

You’ll find this in the HDI concrete example.

Download the HDI to learn more about how errors can be handled to provide appropriate feedback to the user.

 

Avatar
• Product Owner • Marie-Sophie Landrieu-Yvert has joined the 4D Product team as a Product Owner in 2017. As a Product Owner, she is in charge of writing the user stories then translating it to functional specifications. Her role is also to make sure that the feature implementation delivered is meeting the customer need.Marie-Sophie graduated from the ESIGELEC Engineering School and began her career as an engineer at IBM in 1995. She participated on various projects (maintenance or build projects) and worked as a Cobol developer. Then she worked as an UML designer and Java developer. Lately her main roles were analyzing and writing functional requirements, coordinate business and development teams.