Fault Handling in Windows Workflow Foundation

Fault Handling in Windows Workflow Foundation

The purpose of this short write-up is to describe a few ways on how to handle faults or in general exceptions, in Windows Workflow Foundation (WF). I will be using the terms fault and exception interchangeably.

Possible Sources of Faults

There are a number of ways a fault or an exception can occur in a Workflow.

·         Activity Failure –While processing a workflow, an Activity’s execution may fail and give rise to an exception

·         Code Failure – While processing a workflow, code parts for that workflow may also encounter an exceptional condition and a fault may occur

·         Throw Activity – An exception can be deliberately thrown by using a Throw Activity

·         Code Activity – An exception can also be thrown from a Code Activity using “throw “ statement

Consequences of not Handling Faults

If an exception occurs in a workflow and is not handled, the workflow execution is terminated and a “WorkflowTerminated” event is raised by the Workflow runtime. Although you have an option of checking for the exception in this “WorkflowTerminated” event handler, but a better option is to do exception or fault handling as a part of the workflow itself.

FaultHandlers and FaultHandler Activity

When you open a workflow in the workflow designer, you can see the three tabs at the bottom. One of those tabs is called “View Fault Handlers”. Once clicked, it will take to you to the FaultHandlers portion of the workflow. You can add different FaultHandler activities which handles a specific Fault or Exception to this FaultHandlers activity.

You can add a FaultHandler activity to FaultHandlers activity by dragging the FaultHandler activity from the toolbox and dropping it on the FaultHandlers activity surface. But as soon as you do that, you will have to set the “FaultType” property of the FaultHandler activity to a type derivative of Exception type. You can have as many FaultHandler activities as you want inside a single FaultHandlers activity (So far, I am not aware of any limit on the number). 

In the case you have multiple FaultHandler activities; you cannot have more than one FaultHandler with the same FaultType. So if you already have a FaultHandler with FaultType= InvalidOperationException, then you cannot have another one with FaultType= InvalidOperationException. You may see an error popup like this:

SequentialWorkflowActivity can have only one FaultHandlerActivity activity for System. InvalidOperationException.

If you have such as situation then you will not even be able to compile the workflow.

Also, in the case of multiple FaultHandler activities, you will have to arrange those in the order from most specific to most generic FaultType with most specific one being to left and the most generic ones to the right. If you do not do that, then the design will detect it as an error. So the following scenario will not compile: Two FaultHandler activities with the one of the left with FaultType=Exception and with the one on the right with FaultType=ApplicationException. You may see an error popup saying:

A FaultHandlerActivity for exception type 'ApplicationException' must be added before the handler for exception type 'Exception'

You will have to reverse their position to fix the problem. The workflow will not compile unless you fix the order.

Fault Handling Guidelines

Here are some of the guidelines that we have come up based upon the Workflow capabilities for handling faults for workflows

1.     Use try/catch blocks throughput the workflow code to avoid any unforeseen code exceptions

2.     If necessary, create your workflow specific Exception types and FaultHandler activities to throw and catch those exceptions during the course of the workflow. This will help you in indentifying user exception from system exceptions.

3.     So for example, you have a Policy activity in your workflow and you are suing that Policy activity to apply business rules to a certain set of data. And if that set of data fails these business rules then you want to abort the workflow and set a specific error to the data being sent back to the caller of the workflow. To do that efficiently, you need to do a few things:

a.     Create a new type derived from Exception

b.    Add a new FaultHandler with FaultType=newly created type

c.     Throw this newly created exception type wither using a Throw activity or a Code activity

d.    Add a Code activity under the FaultHandler and use that to set specific error message

Please see the attached sample for reference.