Use finally in EC.R rather than catch+throw #11095
Conversation
|
Ah is from the Don't think its relevant for coreclr as its Undo on both sides (in catch or not in catch) |
|
This change alters the ordering between the undo and the invocation of caller filters. Most filters won't be sensitive to this reordering, but user-defined filters in caller frames might be able to tell the difference. Reference source has this same sort of |
|
But that's only handling for the i.e. not saying this change is correct; however the current pattern would only need to be handled for AsyncLocal callback changes? |
|
Maybe add an earlier "if both same/default" check to determine path? (as restore does anyway) |
|
Think have a better way |
4 participants
Allows the opportunity to benefit from Finally Cloning by the Jit.
I didn't quite understand the comment and whether there was some mechanism I wasn't picking up on (e.g. a first chance exception "filter") but not sure what it refers to.
It was from the original open sourcing, so maybe something was different at that time. Exception from the undo for example? (only seems to be a catch -> Environment.FailFast in the undo path)
I checked Reference Source for 4.7 to see if there was more clarity around this comment and it uses finally for undoing the ec in ExecutionContext.RunInternal and not catch+throw.
/cc @jkotas @AndyAyersMS @stephentoub