#Delphi PPL: Does TTask have design flaws?

#Delphi PPL: Does TTask have design flaws?

Recently I posted a few new QCs connected to PPL: 

http://qc.embarcadero.com/wc/qcmain.aspx?d=129159 
http://qc.embarcadero.com/wc/qcmain.aspx?d=129033
http://qc.embarcadero.com/wc/qcmain.aspx?d=129157 

Considering possible causes I begin to think that there are design flaws.

Unlike any other framework in PPL all Wait functions indicate not two but three distinct things:

1) A timeout has occurred;
2) A task has completed successfully i.e. the task was signaled;
3) The task has faulted (canceled/exception);

Raising exception in Wait functions is very unusual, don’t you think? 

I begin to think that it’s unclear what does completion mean. A task should always transition to complete state no matter if it was success, fault (exception) or cancellation. Exceptions during execution affect the result of the task - not its state.
I.e. Tasks should have both Status and Result.

So I think Wait function should unblock upon task’s completion without raising any exceptions. Later the developer can analyze what was the reason for the Wait to unblock – like in any other framework/OS. The Wait function is more related to the state of the task not to its result.

Given that the root cause for the problem in QC129159 is in fact the strange exception raising mechanism. On exception the task itself is added to the FaultedChildren collection. If you don’t call any of the Wait functions so that the exception escapes the ITask the GetExceptionObject is never called and the created circular reference (FaultedChildren) prevents the task to dispose.

What do you think about that?
http://qc.embarcadero.com/wc/qcmain.aspx?d=129159