In this case, the method being called was utilizing a Try/Catch block that simply threw away all exceptions. I implemented some quick logging in the Catch section but also realized that the workflow should probably move to a different state if an exception were to actually occur. So I threw the exception up and started looking at the Workflow Designer and the VS2005 Toolbox to see how to go about catching it.
Interestingly, the solution is easy, but not all that obvious. There is a FaultHandlerActivity, which I quickly spotted and tried to drag onto the workflow. It wouldn't let me stick it anywhere, so I inspected the properties of the different activities already on the workflow for anything that seemed like it might relate to exceptions. Looks like I'd need some help on this one.
So as usual I called my Dad. He's sort of a 51 year-old Casanova, he said "Son, come on over"...
Oops sorry, slipped into Fresh Prince mode for a sec.
Anyways, I did some MSDN reading and some Googling, and discovered that if you enter the detailed view for an EventDrivenActivity (by double-clicking on it in the main workflow view), and right-click the overall EventDrivenActivity object, you get some options I did not know existed:
By selecting the Fault Handler View you are then taken to a different view of the activity where you can drag FaultHandlerActivities and specify which Exceptions to handle and what order they should cascade (similar to how a TryCatch works). You can then drop other activities into each FaultHandlerActivity to perform the actions you want.
In the picture below, I chose to terminate the workflow instance and track the error message to the tracking store.
No comments:
Post a Comment