Exception pattern in Mendix

Home → Knowledgebase → Mendix → Exception pattern in Mendix

“An error has occurred, please contact your system administrator”.

When a user sees this standard Mendix error message, our experience is that the notification is ignored, or contacted that something was wrong. The user just has no idea anymore when exactly or why. Helping becomes difficult.

To improve the feedback that the system gives to the user and achieve more informative logging for the developer, we use a fixed pattern for each action from a page. This looks as follows: It starts with an action nanoflow to handle all customer actions. Think of opening a new page, refreshing an object or showing the user a message. Next, we call an action microflow that executes the logical subflow and handles the result including error handling and logging. The result is returned in a specific FlowResult entity to the nanoflow (see Figure 1).

Figure 1

The pattern for each step looks as follows:

Calling action nanoflow from a page

The action nanoflow is called from a page and is given the prefix “Nanoflow Action Call” (NAC). If validation of fields is required, this nanoflow first calls a microflow for validation. We use a microflow for this, so we can unit test the validation. If you don’t work with unit tests, then a sub-nanoflow will also do, of course. A validation flow returns a result that lets you know whether you can perform the follow-up action or not.

Calling action microflow from nanoflow

The action microflow (with the prefix ACT) is given the same rights as the action nanoflow. This microflow creates a FlowResult object and calls the sub microflow with the logic in it (see Figure 2). On this sub microflow the error handling is captured, so that in case of errors we can log and set the FlowResult to unsuccessful. The error message is also put in the FlowResult. Depending on the result, you can then perform the desired follow-up action in the microflow itself or in the action nanoflow.

Sub microflow from action microflow

The sub microflow handles all logic. Objects are modified here, created and deleted, calculations performed, etc. If an unexpected situation arises, we take care of raising an exception ourselves. This is because it is not the desired and expected behaviour of the logic and thus an execption. This way, the action microflow can catch what went wrong and perform the appropriate handling (including logging).

Figure 2

Considerations for the pattern

• We chose different prefixes (NAC, ACT, SUB) so that you can use the same names for what is often the same functionality. You can therefore use the same and descriptive name, without having to come up with a different name for each flow.
• It remains a consideration whether it is necessary to apply this pattern or not. A simple nanoflow that changes a Boolean attribute to adjust the display does not need this pattern.
• Differentiate between the language in which the user sees the notification (obviously his or her own language) and the language of the notification in the logging. In logging, it is more convenient to store the notification in a language that the developers are familiar with.