Retrieving error messages with Exception Handler in the OutSystems platform
How can we handle errors and display messages to users?
The platform OutSystems has a node -Exception Handler- to create a flow branch that will handle the actions when an error is raised. This Exception Handler flow follows different behaviors that we will be exploring in the section below.
It has a property -only in web apps- named Abort Transaction that could be a little confusing. When this property is set to Yes it will abort the transaction and will rollback all the changes made until there. It will not interfere with the exception handler flow.
Click here if you want to know more about the other properties from Exception Handler.
Use case
So, let’s imagine that we have an application with different modules, and we need to retrieve an error message from producer modules.
So, again, how can we handle errors and display messages to users?
Let’s create a scenario to demonstrate some options. :)
How to
We have a simple page with a button calling a Screen Action. This action has an All Exception Handler flow -we could have more than one exception handler flow, but let’s keep it simple- and a Server Action from another module.
Button and Screen Action triggered
What will the behavior of this flow be like? We have some scenarios to explore because we cannot say what is going to happen only by following this Screen Action.
Let’s go further and dig into the Server Action. We have only an assign node with an expression -a number divided by 0- that raises an exception.
Assign node and truly wrong expression :D
With no Exception Handler
For this first case, in particular, we have no Exception Handler in this Server Action. So as we can see in the image below, the error will be bubbled up and captured by the Exception Handler flow where this action is called -in our case, in the Screen Action.
With Exception Handler
Now we have an Exception Handler flow that ends without taking any action. So when the assign hits the error this exception flow will be triggered and the entire flow will be interrupted without sending any message to the screen. For that reason, we don’t have an image with an error message to demonstrate.
With the Exception Handler flow, the Server Action can be finished in any of these End nodes so we need to configure it properly in the consumer module, in case we want to show a message to users.
With Exception Handler and Output Variables
Let’s change the scenario above.
Now that we have an Exception Handler flow we need to do some changes before treating the error in the consumer module.
Since we want to send error messages and handle the error in the consumer module, we need to create two Output Variables -IsOK and Message. The first one returns a boolean for the Consumer Module to know if the action was successful or not. The second one is a text message with the error in case the action fails.
Exception Handling with Output Parameters
In the Screen Action -Consumer Module- we need to put an IF node to configure the result of the Server Action. If the result returned by the Server Action is False -error inside Server Action- we need to use the error message returned by the output parameter responsible for that to show it to users.
“IF” node with a Feedback Message on False branch
With this approach, we now have personalized error messages and total control of the possible errors.
A better scenario
At least for me!
Imagine that you are working with the previous scenario and almost all of your Server Actions have the variables to receive the boolean result and the exception message. The problem here is that you need to put IF nodes every time you call your Server Actions so you can manage properly the exception returned, increasing the number of nodes in your code.
There is a simple solution for that: we just need to create a User Exception and put it at the end of the Exception Handler flow, just like an End node. And don’t forget to type a customized and a beautiful message in Exception Message property.
Exception Handler flow raising an exception
Screen action and message returned
What happens here is that the exception will be bubbled up and will be caught by the Exception Handler flow from Screen Action. We don’t need to change the main flow -with IF nodes- in Screen Action to treat the exception, as the previous scenario.
Last but not least
Implementing exception flows with the last approach separates functional and exception logic, creating a cleaner and sustainable code.
We should always be implementing good code and do our best to attend the best practices.
How do you retrieve exception messages in your code? Let me know.
:)
Thanks a lot to Neide Gomes that helped me to finish this article!
Like this article? Share it:
