Partager via

Windows Workflow Foundation Exceptions

Les flux de travail peuvent utiliser l’activité TryCatch pour gérer les exceptions déclenchées pendant l’exécution d’un flux de travail. Ces exceptions peuvent être gérées ou être levées à nouveau à l’aide de l’activité Rethrow. Les activités de la section Finally sont exécutées lorsque la section Try ou la section Catches se termine. Les flux de travail hébergés par une instance de WorkflowApplication peuvent également utiliser le gestionnaire d’événements OnUnhandledException pour gérer les exceptions qui ne sont pas gérées par une activité de TryCatch.

Causes des exceptions

Dans un flux de travail, les exceptions peuvent être générées de la manière suivante :

  • Délai d’expiration des transactions dans TransactionScope.

  • Exception explicite levée par le flux de travail à l’aide de l’activité Throw.

  • Exception .NET Framework 4.6.1 levée à partir d’une activité.

  • Exception levée à partir de code externe, comme les bibliothèques, les composants ou les services utilisés dans le flux de travail.

Gestion des exceptions

Si une exception est levée par une activité et qu’elle n’est pas gérée, le comportement par défaut consiste à mettre fin à l’instance de workflow. Si un gestionnaire de OnUnhandledException personnalisé est présent, il peut remplacer ce comportement par défaut. Ce gestionnaire donne à l’hôte de flux de travail l’occasion de fournir la gestion appropriée, telle que la journalisation personnalisée, l’abandon du flux de travail, l’annulation du flux de travail ou la fin du flux de travail. Si un flux de travail déclenche une exception qui n’est pas gérée, le gestionnaire OnUnhandledException est appelé. Il existe trois actions possibles retournées par OnUnhandledException qui déterminent le résultat final du flux de travail.

  • Annuler : une instance de flux de travail annulée est une sortie normale d’une exécution de branche. Vous pouvez modéliser le comportement d’annulation (par exemple, à l’aide d’une activité CancellationScope). Le gestionnaire Terminé est appelé lorsque le processus d’annulation est terminé. Un flux de travail annulé est à l’état Annulé.

  • arrêter : une instance de flux de travail terminée ne peut pas être reprise ou redémarrée. Cela déclenche l’événement Completed dans lequel vous pouvez fournir une exception en raison de son arrêt. Le gestionnaire terminé est appelé une fois le processus d’arrêt terminé. Un flux de travail terminé est dans l’état d’erreur.

  • abandonner - Une instance de flux de travail abandonnée ne peut être reprise que si elle a été configurée pour être persistante. Sans persistance, un flux de travail ne peut pas être repris. À la fin d’un flux de travail, tout travail effectué (en mémoire) étant donné que le dernier point de persistance est perdu. Pour un workflow abandonné, le gestionnaire abandonné est appelé à l’aide de l’exception pour la raison de la fin du processus d’abandon. Toutefois, contrairement à Cancelled and Terminated, le gestionnaire Completed n’est pas appelé. Un flux de travail abandonné est dans un état abandonné.

L’exemple suivant appelle un workflow qui lève une exception. L’exception n’est pas gérée par le flux de travail et le gestionnaire OnUnhandledException est appelé. Les WorkflowApplicationUnhandledExceptionEventArgs sont inspectées pour fournir des informations sur l’exception et le flux de travail est arrêté.

Activity wf = new Sequence
{
    Activities =
     {
         new WriteLine
         {
             Text = "Starting the workflow."
         },
         new Throw
        {
            Exception = new InArgument<Exception>((env) =>
                new ApplicationException("Something unexpected happened."))
        },
        new WriteLine
         {
             Text = "Ending the workflow."
         }
     }
};

WorkflowApplication wfApp = new WorkflowApplication(wf);

wfApp.OnUnhandledException = delegate (WorkflowApplicationUnhandledExceptionEventArgs e)
{
    // Display the unhandled exception.
    Console.WriteLine($"OnUnhandledException in Workflow {e.InstanceId}\n{e.UnhandledException.Message}");

    Console.WriteLine($"ExceptionSource: {e.ExceptionSource.DisplayName} - {e.ExceptionSourceInstanceId}");

    // Instruct the runtime to terminate the workflow.
    return UnhandledExceptionAction.Terminate;

    // Other choices are UnhandledExceptionAction.Abort and
    // UnhandledExceptionAction.Cancel
};

wfApp.Run();

Gestion des exceptions avec l’activité TryCatch

La gestion des exceptions à l’intérieur d’un flux de travail est effectuée avec l’activité TryCatch. L’activité TryCatch possède une collection Catches d’activités Catch qui sont chacune associées à un type Exception spécifique. Si l’exception levée par une activité contenue dans la section Try d’une activité TryCatch correspond à l’exception d’une activité de Catch<TException> dans la collection Catches, l’exception est gérée. Si l’exception est levée explicitement ou si une nouvelle exception est levée, cette exception passe à l’activité parente. L’exemple de code suivant montre une activité TryCatch qui gère une ApplicationException levée dans la section Try par une activité de Throw. Le message de l’exception est écrit dans la console par l’activité Catch<TException>, puis un message est écrit dans la console dans la section Finally.

DelegateInArgument<ApplicationException> ex = new DelegateInArgument<ApplicationException>()
{
    Name = "ex"
};

Activity wf = new TryCatch
{
    Try = new Throw()
    {
        Exception = new InArgument<Exception>((env) => new ApplicationException("An ApplicationException was thrown."))
    },
    Catches =
    {
        new Catch<ApplicationException>
        {
            Action = new ActivityAction<ApplicationException>
            {
                Argument = ex,
                Handler = new WriteLine()
                {
                    Text = new InArgument<string>((env) => ex.Get(env).Message)
                }
            }
        }
    },
    Finally = new WriteLine()
    {
        Text = "Executing in Finally."
    }
};

Les activités de la section Finally sont exécutées lorsque la section Try ou la section Catches se termine correctement. La section Try se termine correctement si aucune exception n’est levée à partir de celle-ci, et la section Catches se termine correctement si aucune exception n’est levée ou rethrown à partir de celle-ci. Si une exception est levée dans la section Try d’un TryCatch et qu’elle n’est pas gérée par une Catch<TException> dans la section Catches ou qu’elle est réexécration à partir de l'Catches, les activités de l'Finally ne seront pas exécutées, sauf si l’un des éléments suivants se produit.

Gestion des exceptions et compensation

La différence entre la gestion des exceptions et la compensation est que la gestion des exceptions se produit pendant l’exécution d’une activité. La compensation se produit après la fin d’une activité. La gestion des exceptions permet de nettoyer une fois l’activité levée, tandis que la compensation fournit un mécanisme par lequel le travail terminé avec succès d’une activité précédemment terminée peut être annulé. Pour plus d’informations, consultez compensation .

Voir aussi

  • Last updated on