Windows Workflow and Error Handling

Unless caught with a fault handler, runtime exceptions in workflow activities terminates the workflow raising the workflow_terminated event. This could be problematic if your controller logic depends on the completion of the workflow wholesale.

Exceptions can be handled at the workflow level, or, for finer-grained exception handling, at the activity level (be it custom or built-in activities).

All sequential workflows have ‘n’ number of activities that can be applied to the designer surface by dragging and dropping an activity from the toolbox (this is also true for custom activities). When custom activities are compiled they become available in the toolbox; a custom activity is any class that derives from SequenceActivity or, more generically, Activity.

To enable error handling select “Fault Handlers” from the activities’ dropdown.

In this screenshot I choose to design an error handler for the “ProcessingData” activity. The fault handler activity is analogous to a try/catch block in code; exceptions in code…you start with catching specific exceptions and work down to generic “Exception” class. In the FaultHandler activity specific to generic fault handlers are arranged left to right.

Since this workflow drives an ADO.Net query I will begin by catching DataServicesRequestException. This is the exception thrown by the server when the service returns a response code less than 200 or greater than 299. Be mindful the Message property of this class will be an XML-encoded message from the server.

From the toolbox find “FaultHandler” and drag it on to the design surface placing it in the fault handler “channel.” Once you’ve added a fault handler it must be set to “catch” a specific exception. Select the fault handler, right click properties and click the ellipses in the “FaultType” property descriptor.

The exception chooser dialog that appears has two tabs; we will be focusing on the “Type” tab. On this tab on the left tree view, a list of all referenced assemblies is displayed; I am going to find “System.Data.Services.Client” and select the “DataServiceRequestException”. Once I’ve chosen the exception I want to handle and click ok, I have the opportunity to bind the fault to a workflow property for inspection by a later activity…and this is exactly what I want to do. To bind the fault I choose “Promote Bindable Properties” from the properties view, which will auto generate a property in the workflow code behind that will store the fault.

Now that I have the “catch” and the fault object itself, I want to do something useful with it. I am going to add a code activity to the fault hander that will simply log the fault and continue.

Double clicking on “codeActivity1” brings me to the code behind.

private void codeActivity1_ExecuteCode(object sender, EventArgs e)
{ 
}

I am going to ignore both parameters in favor of the property I setup earlier, which now stores the actual fault object.

private void codeActivity1_ExecuteCode(object sender, EventArgs e)
{
    Logger.Write(faultHandlerActivity1_Fault2.Message);
}

Using the Enterprise Library, I am going to simply write the faults’ message to disk. Now that I caught the exception in this specific activity, any DataServiceRequestExceptions that are raised during the execution of the activity will no longer result in the workflow being terminated; I log the message and continue. Of course this could be problematic if later activities depend on data from this activity, but I will handle each case appropriately (maybe by using an IfElse activity to programmatically disable activity execution).

If you want to handle all exceptions across all activities, use a fault handler to catch “System.Exception” and the workflow level.