You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've seen too many times developers using .Switch instead of .Match when calling async void code inside the lambdas, because the default behaviour when you want to perform a void operation is to .Switch rather than .Match, resulting in
which isn't awaited correctly (resulting in exceptions being lost)
A .SwitchAsync method which accepts a Func<T, Task> for each parameter would make it really clear than an async option can be used (even gives an IDE hint), and the behaviour would be the same as .Match(Func<T, Task>)
The text was updated successfully, but these errors were encountered:
because the non-async overload is the original and the default for most current usages, i would make the Async part explicit. Omitting async is cleaner when the async version is the default, but omitting it here could still result in the same issue with developers forgetting to await the resulting task
I've seen too many times developers using
.Switch
instead of.Match
when calling async void code inside the lambdas, because the default behaviour when you want to perform a void operation is to.Switch
rather than.Match
, resulting inwhich isn't awaited correctly (resulting in exceptions being lost)
A
.SwitchAsync
method which accepts aFunc<T, Task>
for each parameter would make it really clear than an async option can be used (even gives an IDE hint), and the behaviour would be the same as .Match(Func<T, Task>)The text was updated successfully, but these errors were encountered: