Handling Errors in Workflows (From Microsoft Elearning)

Unexpected circumstances can cause workflows to generate exceptions, exactly as they can with procedural code. For example, if your workflow communicates with a database, but the database server is offline, the workflow may generate an exception. WF includes activities that you can use to handle such exceptions.

Activity

1.FaultHandlersActivity

In a workflow, an exception can occur in the following ways:

A transaction may time out.

You may throw an exception using the ThrowActivity.

Code in code activities or custom activities may throw an exception.

External components may throw an exception.

When an exception occurs in an activity, the runtime transfers it to the parent activity for resolution. The runtime continues to transfer the exception up the workflow hierarchy until it either reaches the top or it reaches a suitable FaultHandlersActivity. Each FaultHandlersActivity contains one or more FaultHandlerActivity objects.

2.FaultHandlerActivity

Each FaultHandlerActivity in a FaultHandlersActivity is associated with a .NET Framework exception type and contains a set of activities that execute to resolve the exception. You can therefore execute different activities for different types of exceptions.

While the FaultHandlerActivity is executing, the activity that threw the exception is in a faulting state. When the FaultHandlerActivity activity completes, the associated activity is put into the closed state.

3.ThrowActivity

You may want to declaratively raise an exception in a workflow. For example, you may want to test a database server early in the workflow, and halt the workflow if the server is not present. In this way you can avoid running code pointlessly.

To raise an exception use the ThrowActivity. You can use this activity to raise any .NET Framework exception type, or to raise an exception that you define in the code-behind file of your workflow.