Closed pdinnissen closed 7 years ago
For asynchronous commands, any exceptions that escape the command delegate are raised on the UI context. This is done deliberately, and matches the behavior of synchronous commands.
If you want to prevent this exception from being raised on the UI context, you should catch it within the delegate you pass to WrapDelegate
.
Even for the TaskCancellationException of the task through CancelCommand?
I see the logic, but I feel that I'm just going to write a wrapper try/catch anyways. How is this any different than the try catch in NotifyTask?
I can see where catching an OperationCanceledException
for that specific CancellationToken
would be desired behavior. I'll re-open this.
Fixed in 1.0.0-eta-03
.
Added a catch for OperationCanceledException
. The CancellationToken
is not checked, since end-user delegates may be using a linked cancellation token.
I get an unhandled TaskCancellationException when cancelling a Command.
I believe you need to add a try catch block to WrapDelegate: