Allow default AsyncFlowControls rather than throwing#82912
Allow default AsyncFlowControls rather than throwing#82912stephentoub merged 1 commit intodotnet:mainfrom
Conversation
|
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
|
Tagging subscribers to this area: @mangod9 Issue DetailsExecutionContext.SuppressFlow currently throws an exception if flow is already suppressed. This makes it complicated to use, as you need to check whether IsFlowSuppressed first and take two different paths based on the result. If we instead just allow SuppressFlow to return a default AsyncFlowControl rather than throwing, and have AsyncFlowControl's Undo nop rather than throw if it doesn't contain a Thread, we can again make it simple to just always use SuppressFlow without any of the other complications. @kouvel, thoughts on doing this? On the one hand, the current exceptions can prevent some misuse. On the other, it makes using the type much harder. On balance I think it's better to make a change like that in this PR, but I'd like your insights.
|
ExecutionContext.SuppressFlow currently throws an exception if flow is already suppressed. This makes it complicated to use, as you need to check whether IsFlowSuppressed first and take two different paths based on the result. If we instead just allow SuppressFlow to return a default AsyncFlowControl rather than throwing, and have AsyncFlowControl's Undo nop rather than throw if it doesn't contain a Thread, we can again make it simple to just always use SuppressFlow without any of the other complications.
|
Seems reasonable to me. I'm not sure how useful the |
|
Cool, thanks. |
|
Nice! Will the API docs be updated automatically to show that these exceptions are now longer a possible outcome? Is the change going to be mentioned in general docs anywhere (or do existing mentions need to be updated) ? Thanks for this very nice little QoL improvement <3 |
Not automatically. We'll need to do so manually once the change hits official preview bits, which should be Preview 3 (since that's what main is currently targeting).
Anywhere the docs currently talk about or show needing to check IsFlowSuppressed we'll want to update with a clarification about pre-.NET 8.
You're welcome. |
ghost
locked as resolved and limited conversation to collaborators
3 participants
ExecutionContext.SuppressFlow currently throws an exception if flow is already suppressed. This makes it complicated to use, as you need to check whether IsFlowSuppressed first and take two different paths based on the result. If we instead just allow SuppressFlow to return a default AsyncFlowControl rather than throwing, and have AsyncFlowControl's Undo nop rather than throw if it doesn't contain a Thread, we can again make it simple to just always use SuppressFlow without any of the other complications.
@kouvel, thoughts on doing this? On the one hand, the current exceptions can prevent some misuse. On the other, it makes using the type much harder. On balance I think it's better to make a change like that in this PR, but I'd like your insights.