Concurrency and Exceptions

[Paul Bjorkstrand]

> We've tried to avoid introducing any new discriminated union, instead we
> are using Future objects to represent a result or exception. The
> completion handler that implements the policy for exceptions can define
> an API to make it easy to access the results or exceptions. The handler
> implementation will need to deal with concurrency but it can define
> something much simpler for the (typically main) task to use.
>

I think this was something I was missing in my original understanding,
thank you for this nugget! I believe treating CompletionHandlers as the
means to _provide_ the results/failures, rather than just _track_ them
makes a lot of sense.

Would you say that the intent of CompletionHandler is to negate, to some
degree, the need to individually call Future.[result|exception]Now()
(outside the handler, that is)? That is what it sounds like to me, and it
makes a CompletionHandler's purpose a lot more useful than just "short
circuit other tasks on the first success/failure".


-Paul