Exception handling in the ACF plugin

Errors can occur in general from time to time. Being a file path the system uses that is not valid anymore, or a misformed SQL statement, a FileMaker calculation with errors in it returns the usual "?" as a function value instead of the expected content.

Some of the user-friendliness of an application is defined in how we deal with such errors.

In the ACF plugin, we have introduced a new construct for dealing with this, as you find in many other programming languages.

The TRY / CATCH error handler.

Take a look at this function:

• In the ACF language, if the TRY block executes without any errors, the CATCH block is bypassed. However, if an exception occurs—either due to an error in a function within the TRY block or a THROW statement—the execution immediately jumps to the CATCH block of the current function. This behavior effectively halts the call hierarchy and shifts control to the CATCH section where the TRY block is implemented, ensuring that exceptions are handled at the highest level in the call hierarchy where there is an exception handler.

The WriteReport function in the ACF language is working as intended with the try/catch and try again logic:

1. When an exception occurs in open, the catch block is triggered.
2. The confirm dialog lets the user decide whether to select a new file.
3. If the user chooses a new file and the path is not empty, try again is invoked to retry the file opening.
4. If the user cancels the file selection (resulting in an empty path), the function throws a new error and aborts.

This implementation correctly handles file opening errors and gives the user a chance to rectify the problem by choosing a new file path. The try again mechanism, along with a user-friendly confirm dialog, enhances the robustness of the function. The additional throw at the end ensures that the function does not proceed with an invalid file path.