Slight Workflow Annoyance

One of the cool things about WF is that you can specify the GUID it uses to identify a workflow instance. WorkflowRuntime.CreateWorkflow has an overload (actually two) where you can specify said workflow instance identifier. This is awesome for using WF with Service Broker, as Service Broker already has the idea of a conversation group which is roughly analogous to a workflow instance. Conversation groups even use a GUID identifier, so there’s not even any mapping required to go from conversation group to workflow instance.

However, things get less cool when you call WorkflowRuntime.GetWorkflow. If you call GetWorkflow with a GUID that has no corresponding workflow instance, it throws an InvalidOperationException instead of just returning null. That seems like an odd choice. If you’re going to support specifying the instance identifier when you create the workflow instance, doesn’t it make sense that you should also gracefully support the scenario where an instance identifier is invalid?

I see two ways to deal with this:

  • Iterate through the list of loaded and persisted workflow instances looking for the one in question.
  • Call GetWorkflow and swallow the exception.

I ended up picking the “Swallow the Exception” approach as I can’t imagine the iteration thru every loaded and persisted instance would be very performant. But swallowing exceptions always makes me feel icky. I’m a fan of the “exceptions only for exceptional situations” approach and as far as I’m concerned, an invalid instance identifier isn’t that exceptional. Still, it’s a minor annoyance, especially given how cool it is to be able to specify the workflow instance identifier in the first place.

This entry was posted by DevHawk on November 3, 2006. It was posted in Development. It was tagged Service Broker and WF.

Comments:

I'd respectfully tend to disagree. I am a firm believer in the idea that exceptions should be thrown when a method can't perform the operation which is implied by its name. (This is a bit more concrete than the "exceptional condition"). Which now means that the semantic implication of "get" (as in GetWorkflow) is the thing we'd need to argue about. Here, I usually tend to prefer the pattern that get/load/retrieve-methods do indeed throw an exception if the can't get the specified item (after all, they couldn't do what their name implies) whereas methods like FindWorkflow() - if they would exist - would happily return empty lists if there were no matches for the given criteria. In essence, I would have expected the WF runtime to perform this operation exactly in the way it does. Just my 2c, -Ingo
This comment was posted by Ingo Rammer on November 03, 2006 at 1:10 PM.

Categories

Tags

Series

Disclaimer

The information in this weblog is provided "AS IS" with no warranties, and confers no rights. This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion. Inappropriate comments will be deleted at the authors discretion.