Click here to Skip to main content
Click here to Skip to main content
Technical Blog

Tagged as

Windows Workflow and Error Handling

, 4 Aug 2010 CPOL
Rate this:
Please Sign up or sign in to vote.
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).

image

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.

image

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.

image

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.

image

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.

image

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.

image

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.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

thebacon

United States United States
No Biography provided

Comments and Discussions

 
-- There are no messages in this forum --
| Advertise | Privacy | Mobile
Web03 | 2.8.141015.1 | Last Updated 4 Aug 2010
Article Copyright 2010 by thebacon
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid