There are two ways to handle exceptions in a rule set:
- Resulting Exception Event—creating rules that are directly connected to the resulting exception event on an action.
The advantage to this approach is that a complete rule execution chain leading up to the action is available and as a result more information about the problem can be reported as part of handling the exception.
The disadvantage is that it can result in a lot of duplicate rules if there are multiple actions in a rule set where exceptions could be thrown.
- Root Exception Event—adding a root exception event to the rule set and connecting rules to it.
The advantage to this approach is that regardless of where in the rule chain the exception occurred, it will be captured and reported.
The disadvantage is that the context that led up to the exception is no longer available. All that is available to be reported is the name of the rule that the exception originated from and a message related to the exception.
A hybrid approach is generally the best strategy. Implement the resulting event exception handler where detailed context information is needed but provide a root event exception handler for all other exceptions.
Prior to Prinergy 6, if both exception handlers were implemented both would be executed. The resulting event exception handler rule chain would be executed and then the root event exception handler rule chain would be executed. This would sometimes result in duplicate error reporting. As of Prinergy 6, the exception handling behavior has changed. Now only if a resulting event exception handler is not implemented on the action does the root event exception handler execute. In order to allow you to replicate the old behavior, a Throw action has been added in to allow you to propagate exceptions from the resulting event exception handler to the root exception event handler.
Note: As of Prinergy 6.1.1, the Throw action is not working correctly due to bug PRINERGY-34294. Attempting to place it in a rule set causes Rule Builder to crash.