Exception Management can be divided into the process for testing and removing exceptions and the process of handling exceptions. Exceptions are defined as any deviation between what the user expects and what the application does. They were divided into three types based on where in the DevOps process they were uncovered, and categorized into three groups based on how they would be addressed by the development team. In this article, we focus on bugs and how to prevent them from causing the application to behave unexpectedly. This area of Exception Management is called Exception Handling.
“A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.”
Douglas Adams
Any system that has users will have exceptions. Our goal as a developers is to handle those exceptions so that the system corrects them before the user notices, or so that user understands what went wrong. In the last article we discussed how errors are found and eliminated in the development lifecycle so they are prevented from becoming failures in production. No matter how hard we try, there are going to be situations where the application is unable to successfully process a user request. If these situations aren’t handled, they become failures for the user when something they expected to happen didn’t.
Exception Handling
Once the development team has finished the code and it works correctly it is handed over to the testing team. During testing, the programming is run under many different usage situations. The defects that are found can come from three different sources. External Exceptions come from outside the programming. These can be environmental variables such as the operating system, the layout used, or the user permissions. Internal Exceptions come from within the programming. These happen when our script is unable to perform the actions, such as not finding the right records, or setting a field from an unrelated table. Interface Exceptions are caused by invalid user requests. This could be a user failing to enter a required field, or entering text for a phone number.
In each of these situations, the defect is not because the code is wrong, it’s because the code fails to resolve errors before they become failures for the user. In Exception Handling, we want the code to correct or alert the user to any of these unusual situations that the program can achieve a successful response for the user.
Try – Throw – Catch – Finally
A common practice for handling errors as they occur is the Try – Catch code block. This function is built into javascript and other coding languages. It works like this:
try {
//some action
if ( action_fails ) {
throw ( some_error )
}
}
catch ( some_error ) {
//perform some other action if some_error
}
finally {
//execute these actions after
}If an error occurs in the Try block, then the Catch block will execute, and then the Finally block will execute. If an error doesn’t occur, the Catch block is skipped and the program goes directly to the Finally block. By detecting the error, and then performing some additional actions to correct the error, the program is able to achieve a successful response without the user noticing the original error. This is called an Exception Recovery, since the error was corrected before causing a failure. Another possible outcome is an Exception Request. An Exception Request prompts the user for additional information, before continuing with the execution. This could be a prompt to submit a required field or to choose a different file type to upload.
The Try Loop in FileMaker
The Try – Catch pattern has the benefit of separating the programming for normal operation from the programming for Error Handling. If the operation is successful, all the error handling is skipped entirely. FileMaker doesn’t come with any built in error handling process. However, the tools for a developer to build their own standard error handling pattern are provided. One pattern that can be used in FileMaker scripting is the Try Loop. In this example, the normal operation to be tried is put into a loop. If it is successful, the program exits out of the loop to the Finally steps. If an exception is thrown, then the program will run the Catch steps.
The Try Loop has the benefit of having only one successful program path, often called the “happy path”. This is the code the developer tests when everything just works right. In the real world, many things can go wrong. The code handles the exceptions by detecting them in the Throw block and fixing them in the Catch block, and then retrying the normal operation. This limits the number of exception branches that sprout as developers try to handle an increasing number of exceptions. Using If – Else statements to handle various exceptions results in a complicated execution order with logic that can be difficult to trace. The Catch block is only responsible for correcting the exception, by an automated recovery or by a user request, before trying the normal operation again. If the exception can’t be corrected, the Catch block can warn the user and process a safe failure.
Next Steps
In another article we’ll look at processes for testing and detecting external, internal, and interface exceptions, catching them to be corrected even before the normal operation even runs. By declaring the exceptions that can be predicted, we can throw exceptions that are caught and fixed to create robust software that avoids failure. Once the expected exceptions are declared, it becomes much easier to write automated tests that purposefully create the exception to verify the exception is handled correctly. The Try Loop is a good start for developers interested in building more robust and structured Exception Handling techniques.
Thx!