Workflow 4 Bugfest - no compensations

According to msdn

"Compensation in Windows Workflow Foundation (WF) is the mechanism by which previously completed work can be undone or compensated (following the logic defined by the application) when a subsequent failure occurs. This section describes how to use compensation in workflows."

Ok. Lets start with this very simple example:


But when you execute it you will find that...

Pufffff, it's gone!

None of our handlers is ever called. Our transaction is down the drain.

Hmm, maybe the transaction was not successful and this is the reason why none of handlers got called.

Lets try this:

But when you execute it you will find that...

the last message is "Do Transaction" then

Pufffffs, it's gone.

But on the other hand what happens if we delete the throw?

Then we see that the confirmed handler gets called at the end of our workflow.

This means:

If we use CompensableActivity and everything in our workflow completes successfully, the transaction gets "autocommitted". Otherwise its puffff gone.

But this behavior can be changed from outside.

Lets wrap the first example into one of this mysterious Try/Catch Block and let him handle the exception.



What we now see that all of a sudden our CancellationHandler gets called.

I am confused now.

First thing is that I would never expect my Compensation to just puffff. I mean I do serious thing in a compensation. This makes especially no sense to me, if a successful Compensation auto-commits and the end of the workflow. An even less if failed compensation calls the cancellationhadler only if it is wrapped into a Try/Catch block that handles the exception.

Update: In the MSDN Forum Steve Danielson investigated the issue and gave an excellent hint on the difference between C# Try/Catch and Workflow Try/Catch. This covers the behavior for CompensableAction as well

Workflow 4 Bugfest - The Exception handling bug

I currently dig into Workflow 4 (Final). After Workflow 3 really drove me nuts with its unbearable performance I was first positively impressed by Workflow 4. The designer as well as the workflow execution speed is there where I expect it to be.
I downloaded the samples and went through the basic shapes section. All fine here.

But my impression is about to change, as Workflow 4 seems to contain a number of serious bugs.

This becomes very evident if you look at the execution of the finally block in a try/catch activity.

According to msdn...

"The finally block is useful for cleaning up any resources allocated in the try block as well as running any code that must execute even if there is an exception. Control is always passed to the finally block regardless of how the try block exits."

The most simple form of a try-Catch Activity is this:

Please note that there is no Exception handler in the "Catches" section. I simply want the Exception to propagate, but before it does that I want to make sure my code block in finally is executed no matter what happens.

But if you now execute the code, you will find out that the code in our finally block never gets executed....

This will not change if you add an exception handler, that does not handle the specific exception.

To make things worse we will see, that even if we handle the specific exception and and want to rethrow it, our finally is never executed.

Actually the only time the finally gets executed in case of an exception is when the Exception is handled and not propagated.

This means:

In Workflow 4 you cannot propagate an exception and execute a finally block.

In other words:

You cannot use a finally block.

Update: In the MSDN Forum Steve Danielson gave an excellent hint on the difference between C# Try/Catch and Workflow Try/Catch.