Stephen Toub has some more information on the reasoning in this thread.
To summarize, it’s not a good idea for two reasons:
- It promotes unstructured code. If you have “heavy processing” that you need to do, it should be placed in a
Task.Run
. Even better, separate your business logic from your UI logic. - Error handling and (some) continuations run in an unknown context.
catch
/finally
blocks inTest
would need to handle running in a thread pool or UI context (and if they’re running in the thread pool context, they can’t useSwitchTo
to jump on the UI context). Also, as long as youawait
the returnedTask
you should be OK (await
will correct the continuation context if necessary), but if you have explicitContinueWith
continuations that useExecuteSynchronously
, then they’ll have the same problem as thecatch
/finally
blocks.
In short, the code is cleaner and more predictable without SwitchTo
.