Try/Catch/Finally

The try/catch/finally structure is a fundamental part of error handling in Web Amendability. It allows you to handle errors and exceptions that may occur during the execution of your code. By utilising try/catch/finally blocks, you can implement custom error handling logic and provide a smooth user experience by displaying relevant success or error messages.

• Try Block: The try block is used to enclose the code that might throw an error or exception. It is where you place the code that needs to be executed and monitored for any potential errors. If an error occurs within the try block, it is immediately caught by the catch block, preventing it from disrupting the normal flow of the application.

• Catch Block: The catch block is executed when an error or exception is thrown within the try block. It allows you to define specific error-handling logic to handle the caught error. In the Web Amendability, catch blocks are often used to display error messages to the user or perform additional actions based on the type of error encountered. It provides you with an opportunity to handle errors and guide users through the error resolution process.

• Finally Block: The finally block is optional and is executed regardless of whether an error occurred or not. It is useful for performing cleanup tasks or releasing resources that need to be executed regardless of the outcome.

"tryCatch": {
  "noThrow": [],
  "try": [
    {
      "apiPut": {
        "endpoint": "v1/departments",
        "prefix": "",
        "id": {
          "get": {
            "state": "dept_id"
          }
        }
      }
    },
    {
      "set": {
        "success_message": "Department updated successfully"
      }
    },
    {
      "resetState": {}
    }
  ],
  "catch": [
    {
      "set": {
        "error_message": {
          "title": "Error updating Department",
          "message": {
            "get": {
              "state": "CURRENT_ERROR"
            }
          }
        }
      }
    }
  ]
}

In this example, the try block contains an “apiPut” operation to update a department. If an error occurs during the API request, the catch block is executed. It sets the “error_message” state, which includes a title and a message retrieved from the “CURRENT_ERROR” state. This allows you to display a meaningful error message to the user, notifying them of the error that occurred.

success_message: The success_message option allows you to display a custom message when an action or operation is successfully completed. It provides a way to communicate important information or confirmations to the user, enhancing their understanding and user experience.

    {
      "set": {
        "success_message": "Department updated successfully"
      }
    },

error_message: The error_message option enables you to define and display custom error messages when errors or exceptions occur. It helps users understand what went wrong and guides them towards appropriate actions, improving the overall user experience.

• The “title” property represents the title of the error message, providing a brief summary of the encountered error.

• The “message” property contains the detailed description or explanation of the error, including any instructions or suggestions for resolution.

  Additionally, you can use the “get” property within the “message” property to dynamically retrieve the current error from the application’s state. This can be useful when you want to display the specific error message that occurred during the operation.

{
  "set": {
    "error_message": {
      "title": "Error updating Department",
      "message": {
        "get": {
          "state": "current_error"
        }
      }
    }
  }
}

noThrow: By default, when your code encounters an error or exception, the catch handler is triggered. It executes its designated code and then proceeds to rethrow the error or exception. This ensures that the Sage 200 form framework also becomes aware of the error and performs its appropriate error handling procedures. Typically, this involves retaining the form’s content without clearing it and omitting the display of a ‘success’ message.

However, there may be specific scenarios where the developer intends to bypass the form’s error handling mechanism. In such cases, they can utilise the noThrow option to prevent the error from being rethrown. By employing this option, the form can seamlessly continue its execution on the success path, if the core form’s function itself did not encounter any errors.

In summary, the default behaviour is to catch and rethrow errors for the forms framework’s error handling, but developers have the flexibility to opt out of this behaviour using the “noThrow” option if desired.

"tryCatch": {
  "noThrow": [],
  "try": [
...    

It is important to note that the use of “noThrow” should be approached with care and consideration. Prior to implementing this option, it is essential to thoroughly test and validate your error handling approach to ensure it aligns with the requirements of your application and does not compromise the stability and functionality of the sreeen.