Page History

There are two ways to handle exceptions in a rule set:

1. 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.
    
2. 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.

Es gibt zwei Möglichkeiten zum Behandeln von Ausnahmen in einer Regelsammlung:

1. Resultierendes Ausnahmeereignis: Regeln werden erstellt, die direkt mit dem resultierenden Ausnahmeereignis einer Aktion zusammenhängen.

Der Vorteil dieses Ansatzes ist, dass eine vollständige Ausführung der Regelkette bis zur Durchführung der Maßnahmen zur Verfügung steht und deshalb mehr Informationen über das Problem als Teil der Behandlung der Ausnahme berichtet werden können.
Der Nachteil ist, dass viele doppelte Regeln entstehen können, wenn mehrere Aktionen in einer Regelsammlung sind, in denen Ausnahmen entstehen können.

1. Root-Ausnahmeereignis: Hinzufügen eines Root-Ausnahmeereignisses zur Regelsammlung und Verbinden der Regeln damit.

Der Vorteil dieses Ansatzes ist, dass, unabhängig davon, wo in der Regelkette die Ausnahme aufgetreten ist, sie erfasst und gemeldet wird.
Der Nachteil ist, dass der Kontext, der zur Ausnahme geführt hat, nicht mehr verfügbar ist. Es steht nur der Name der Regel, in der die Ausnahme aufgetreten ist, und eine Nachricht, die sich auf die Ausnahme bezieht, für die Berichterstellung zur Verfügung.
Ein hybrider Ansatz ist allgemein die beste Strategie. Implementieren Sie den Handler für resultierende Ausnahmeereignisse, wenn detaillierte Kontextinformationen benötigt werden, aber stellen Sie einen Root-Ausnahmeereignis-Handler für alle anderen Ausnahmen bereit.
Wenn vor Prinergy 6 beide Ausnahme-Handler implementiert wurden, wurden beide auch ausgeführt. Die Regelkette des Handlers für resultierende Ausnahmeereignisse wurde ausgeführt, bevor die Regelkette des Root-Ausnahmeereignis-Handlers ausgeführt wurde. Dies führte manchmal zu doppelter Fehlermeldung. In Prinergy 6 wurde das Verhalten der Ausnahmebehandlung geändert. Jetzt wird der Root-Ausnahmeereignis-Handler nur dann ausgeführt, wenn ein Handler für resultierende Ausnahmeereignisse nicht in der Aktion implementiert wurde. Um das alte Verhalten zu replizieren, wurde die Aktion Werfen hinzugefügt, damit Sie Ausnahmen vom Handler für resultierende Ausnahmeereignisse in den Root-Ausnahmeereignis-Handler weitergeben können.
Anmerkung: In Prinergy 6.1.1 funktioniert die Aktion Werfen nicht richtig wegen des Fehlers PRINERGY-34294. Der Versuch, sie in einer Regelsammlung zu implementieren, führt zum Absturz des Regelgenerators.

有两种方法来处理规则集中的异常：

1. 生成异常事件 — 创建的规则直接连接到操作所生成的异常事件。

这种方法的优点是，可以获得导致操作的完整规则执行链，因此作为异常处理的一部分，可以报告关于问题的更多信息。
缺点是，如果可能抛出异常的规则集中有多个操作，它可能导致很多重复的规则。

1. 根异常事件 — 向规则集中添加一个根异常事件，然后将规则连接到该事件。

这种方法的优点是，无论异常发生在规则链中的何处，它都将被捕获并报告。
缺点是导致异常的上下文信息不再可用。 所有可供报告的信息只有发生异常的规则名称，以及与异常相关的消息。
混合的方法通常是最佳策略。 实施需要详细上下文信息的生成事件异常处理程序，但为所有其他例外提供一个根事件异常处理程序。
在印能捷 6 之前，如果实施了两种异常处理程序，两者都将执行。 将执行生成事件异常处理程序规则链，然后将执行根事件异常处理程序规则链。 这有时会导致重复的错误报告。 从印能捷 6 开始，异常处理行为发生了变化。 现在只有操作未实施生成事件异常处理程序时，才会执行根事件异常处理程序。 为了让您可以重复旧的行为，添加了一个抛出操作，让您可以将异常从生成事件异常处理程序传播到根异常事件处理程序。
注： 由于错误 PRINERGY-34294，抛出操作从印能捷 6.1.1 起工作不正常。 尝试将其置于规则集中将导致规则生成器崩溃。

Hay dos formas de manejar las excepciones que se producen en un conjunto de reglas:

1. Evento de excepción resultante: creación de reglas que están conectadas directamente al evento de excepción resultante de una acción.

La ventaja de este método es que hay disponible una cadena de ejecución de reglas completa que llevan a la acción y, por ello, se puede informar con más detalle acerca el problema al manejar la excepción.
La desventaja es que puede provocar gran cantidad de reglas duplicadas si hay varias acciones en un conjunto de reglas en el que se podrían generar excepciones.

1. Evento de excepción raíz: adición de un evento de excepción raíz al conjunto de reglas y conexión de las reglas al mismo.

La ventaja de este método es que, independientemente de la ubicación de la cadena de reglas en la que se produzca la excepción, se capturará y se informará de ella.
La desventaja es que el contexto que condujo a la excepción ya no está disponible. La única información disponible es el nombre de la regla en la que se originó la excepción y un mensaje relacionado con la excepción.
Un método híbrido suele ser la mejor estrategia. Implemente el gestor de excepciones de evento resultante donde se necesite información detallada del contexto, pero proporcione un manejador de excepciones de evento raíz para todas las demás excepciones.
Antes de Prinergy 6, si se implementaban ambos gestores de excepción, se ejecutaban ambos. Se ejecutaba la cadena de reglas del gestor de excepciones resultante y, a continuación, se ejecutaba la cadena de reglas del manejador de excepciones de evento raíz. Esto provocaba, en ocasiones, un informe de errores duplicado. A partir de Prinergy 6, el comportamiento del manejo de excepciones ha cambiado. Ahora, solo si no se implementa un manejador de excepciones de evento resultante en la acción, se ejecuta el manejador de excepciones de evento raíz. Con el fin de permitir replicar el comportamiento anterior, se ha agregado una acción Throw para permitir que propague las excepciones del manejador de excepciones de evento resultante al manejador de eventos de la excepción raíz.
Nota: A partir de Prinergy 6.1.1, la acción Throw no funciona correctamente debido al error PRINERGY-34294. Tratar de colocarla en un conjunto de reglas hace que el Generador de reglas se bloquee.

Vous pouvez gérer les exceptions dans un jeu de règles de deux façons :

1. Événement d'exception résultant : création de règles directement liées à l'événement d'exception résultant au moment d'une action.

L'avantage de cette méthode est qu'une chaîne complète d'exécution de règles débouchant sur l'action est disponible. Ainsi, plus d'informations sur le problème peuvent être signalées dans le cadre de la gestion de l'exception.
L'inconvénient est que cela peut créer un nombre important de règles en double si plusieurs actions d'un jeu de règles peuvent faire l'objet d'exceptions.

1. Événement d'exception racine : ajout d'un événement d'exception racine au jeu de règles et association de règles.

L'avantage de cette méthode est que l'exception est détectée et signalée peu importe où elle se produit dans la chaîne de règles.
L'inconvénient est que le contexte ayant amené à l'exception n'est plus disponible. Les seuls éléments pouvant être signalés sont le nom de la règle à l'origine de l'exception et un message concernant l'exception.
Une méthode mixte constitue généralement la meilleure approche. Mettez en œuvre le gestionnaire d'exception d'événement résultant si des informations de contexte détaillées sont nécessaires mais faites appel à un gestionnaire d'exception d'événement racine pour toutes les autres exceptions.
Avant Prinergy 6, si les deux gestionnaires d'exception étaient mis en œuvre, les deux étaient exécutés. La chaîne de règles du gestionnaire d'exception d'événement résultant était d'abord exécutée, suivie de celle du gestionnaire d'exception d'événement racine. Mais les erreurs étaient parfois signalées en double. À partir de Prinergy 6, les exceptions sont gérées différemment. Désormais, le gestionnaire d'exception d'événement racine n'est exécuté que si aucun gestionnaire d'exception d'événement résultant n'est mis en œuvre pour l'action. Pour utiliser l'ancien comportement, une action Lancer a été ajoutée afin que vous puissiez propager les exceptions depuis le gestionnaire d'exception d'événement résultant vers le gestionnaire d'exception d'événement racine.
Remarque : Dans Prinergy 6.1.1 et versions ultérieures, l'action Lancer ne fonctionne pas correctement en raison du bogue PRINERGY-34294. Lorsque vous essayez de l'utiliser dans un jeu de règles, le Créateur de règles ne répond plus.

ルール セット内の例外を処理するには、以下の 2 つの方法があります。

1. 結果例外イベント — アクションで結果の例外イベントに直接接続されるルールを作成します。

この方法の利点は、アクションに至る完全なルール例外チェーンを使用できること、およびその結果として、例外処理の一部として問題に関するより多くの情報を報告できることです。
欠点は、例外を発生させる可能性があるルール セット内に複数のアクションが存在する場合に、多くの重複するルールが使用される可能性があることです。

1. ルート例外イベント — ルート例外イベントをルール セットに追加してルールを接続します。

この方法の利点は、ルール チェーン内の例外が発生した場所に関係なく、例外が取得および報告されることです。
欠点は、例外に至るまでのコンテキストが使用できなくなることです。 報告に使用できるのは、例外の発生元のルールの名前および例外に関連するメッセージのみです。
通常は両方を組み合わせた方法が最も効果的です。 詳細なコンテキスト情報が必要な場合は結果イベント例外ハンドラを実装しますが、他のすべての例外に対してはルート イベント ハンドラを提供します。
Prinergy 6 より前には、両方の例外ハンドラが実装された場合、両方のハンドラが実行されていました。 結果イベント例外ハンドラ ルール チェーンが実行され、その後でルール イベント 例外ハンドラ ルール チェーンが実行されます。 この結果、エラーが重複して報告されることがありました。 Prinergy 6 では、例外処理の動作が変更されています。 現在は、アクションで結果イベント例外ハンドラが実装されていない場合のみ、ルート イベント例外ハンドラが実行されます。 ユーザーが以前の動作を再現できるようにするために、例外の送信アクションが追加されており、結果イベント例外ハンドラからルート例外イベント ハンドラに例外を伝達することができます。
注: Prinergy 6.1.1 では、バグ PRINERGY-34294 のために例外の送信アクションは正常に動作しません。 ルール セットに設定しようとすると、ルール ビルダがクラッシュします。