Allow yield inside of try / catch and catch #8413
Conversation
This proposal expands the use of `yield` to - `try` portion of a `try / catch` block - `catch` portion of a `try / catch` block with some restrictions around `finally`
|
Regarding |
I think the big problem is agreeing on what behavior Basically I think the problem is more along agreeing what behavior is correct vs. implementing that behavior. Can add this to open issues though in case there is broad agreement on what the best behavior is. |
proposals/yield-in-try-catch.md
Outdated
|
|
||
| ### Code generation yield inside try / catch in async iterators | ||
|
|
||
| The code generation for `try / catch` blocks in async iterators will be largely the same as traditional iterators. The difference is that the return type of generated `catch` methods will be `ValueTask` instead of `void`. |
There was a problem hiding this comment.
I didn't follow this. Async iterators are more like async state machines than iterator state machines.
Instead of generating a MoveNext and a Dispose method with similar structure, we use a single method (MoveNext) for both normal and disposal execution. A flag indicates if we're in disposal and we use it to skip over non-disposal code as appropriate.
So we shouldn't need to generate catch methods.
Here are some notes on disposal in async iterators. Happy to discuss offline.
There was a problem hiding this comment.
Hmm. Maybe i was looking at the wrong code gen here. Will take a look at this.
Co-authored-by: Jan Jones <[email protected]>
|
May I suggest that instead of resetting the stack trace, (It should be |
proposals/yield-in-try-catch.md
Outdated
|
|
||
| ### Dispose and finally in async iterators | ||
|
|
||
| The `DiposeAsync` behavior for async iterators mirrors that of traditional iterators in that it executes the `finally` blocks at the the point the state machine is suspended. However it does this by setting the `state` variable to a value that represents disposing and then calls `MoveNextAsync`. The implementation of `MoveNextAsync` will then execute only the `finally` blocks for the suspend point. The `DisposeAsync` method does not have a mirror copy of the `finally` blocks. |
There was a problem hiding this comment.
Curious, is there some reason why the codegen of DisposeAsync is different from Dispose? #Resolved
There was a problem hiding this comment.
I suspect it's mostly an accident of history. The async state machine didn't have to deal with Dispose scenarios initially hence never went through the necessary rewriting process. At the point we added async iterators it was easier to just tweak the state field to represent disposing and using the existing state machine.
@jcouv can confirm or give a better explanation ;)
There was a problem hiding this comment.
Yes, it was simpler and more elegant/lightweight to use a single state machine with a "disposal" flag for async-iterators. I was aware of the codegen for iterators but didn't see a benefit to the added overhead (second state machine with bunch of logic extracted into helper methods).
| 2. The contents of the `when` clause will be generated into a parameterless method on the iterator with a `bool` return. | ||
| 3. The `catch` block will be replaced with a call to the generated method in `MoveNext`. | ||
| 4. The `when` clause will be replaced with a call to the generated method in `MoveNext`. | ||
| 5. The `Dispose` method will mirror `catch` and `finally` blocks in the same way it mirrors `finally` blocks today and dispatch to the appropriate method |
There was a problem hiding this comment.
Could we also do codegen similar to async iterators, i.e., share MoveNext and Dispose implementations?
There was a problem hiding this comment.
That is definitely an option, essentially changing iterators to favor the async iterators code gen approach. I think that would be fine as I can't see any technical reason why iterators have to be done that way but we'd want to vet it out a bit
Co-authored-by: Jan Jones <[email protected]>
Co-authored-by: Julien Couvreur <[email protected]>
This proposal expands the use of
yieldtotryportion of atry / catchblockcatchportion of atry / catchblock with some restrictions aroundfinally