If you don't properly handle exceptions in the workflow and an error occurs, you'll get the dreaded "Error Occurred" string in the workflow status, with no help as to what went wrong. You're left with debugging your workflow, and if you don't know how to debug, you're really up a creek.
Let's start with what's easy, debugging. You debug your workflows almost the same way as any other .NET application you build. Within your workflow's code view, right click on the line of code where you want to start debugging, and choose Breakpoint, Insert Breakpoint (Figure 1). Also note, you can debug the activities on the template themselves. To do this, simply right click the activity you want to debug, and select Breakpoint, Insert Breakpoint again.
Figure 1 You debug a workflow in almost the same way you debug any .NET program. Simply add a breakpoint and attached to the SharePoint process.
The next thing to do is attach the Visual Studio debugger to the w3wp SharePoint process (Figure 2). In Visual Studio still, click the Debug menu drop down, and select Attach to Process. Scroll down and select the w3wp process and click Attach. If there are multiple w3wp processes, select all that show up. If you don't see the process, navigate to the SharePoint site to start the process, then go back to the process list and click the refresh button. After you attach you can start your workflow and Visual Studio will automatically step into the debugger when the line of code or activity hits.
Figure 2 You must attach to the w3wp SharePoint process to debug your SharePoint workflows.
Handling exceptions however, are a bit different than your standard .NET application. When you're in a workflow template there's no obvious place to add a Try/Catch block. Many developers end up never handling exceptions and they end up spending a lot of time debugging just trying to figure out where the error occurred. Instead, the better approach is to use the FaultHandler activity at the root of your workflow (green arrow) as well as all your composite activities (sequence, parallel, IfElse, etc).
Within the FaultHandler activity, you can insert activities that handle the error in an appropriate way. For SharePoint, a popular thing to do is log the error, location, and stack trace into the workflow's history list. This makes determining the error and location very easy to do.
At the very least, every workflow should have a Fault Handler setup at the root of the workflow template. To do this, click the dropdown next to the green arrow and select View Fault Handlers.
Within the fault handlers section, you can drag and drop one or more FaultHandler activities. Each activity has a property called FaultType and you need to set this property to the type of exception you want to handle. To handle all exceptions, set it to System.Exception, which is the most generic exception (Figure 3). Alternatively, you could set it to a custom exception to handle errors that are very specific to your workflow. This is the best approach because then debugging is very easy because you'll know when and why your own custom exceptions are being raised.
Figure 3 When you add a fault handler, you need to specify what exception to handle.
After you have specified what exception to handle, you should add some actions to react to the error appropriately. A helpful thing to do is use the log to history list activity to log a more descriptive error and maybe even the stack trace to help debugging (Figure 4).
Figure 4 After you've specified what exception to handle, it's a good idea to log a good error description, and possibly the stack trace to help with debugging. You can do this by dropping the log to history list activity within the fault handler.
Phil