Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
vm: rework the exception handling #1061
vm: rework the exception handling #1061
Changes from 2 commits
0fa6d3b
453140c
d632598
c817ca0
3b8c28a
812bb09
d33acc5
6e9f7ec
5830868
8d68357
1b51e92
960185a
7a0a245
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking this through myself:
Reading through my characterization, I think the 'precise' question is, should a
finally
be allowed re-parent an existing exception (cancellation)? I believe the answer is "yes, it should" because if not then, the property we'd be after is thatfinally
cannotraise
, which seems infeasible/not very useful. I consider this a variant of raising an entirely new exception that overrides the old one, except in this case our 'new exception' 'adopts' the data of the old one.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, I'm not sure I completely follow. A
finally
could be allowed to raise without having to allow re-targeting an existing exception to a handler within thefinally
(e.g., by disallowing re-raise outside ofexcept
branches.In your model, would line 28 be executed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a great question, I want to say yes. But that would mean we entered the
finally
through exceptional means, it handled the exception internally, then the treatment would have to be flipped to non-exceptional.Which seems to defer the determination of how to leave a
finally
that much more. Where each control flow branch within afinally
can change the handling... ooph.Perhaps a static restriction is a better bet, because we can always lift the restriction later when/if we're willing to do that extra analysis and think through all the implications (extra accumulated experience in the future will also be beneficial).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, this is the reason why I'd prefer not supporting the re-targeting.
Okay, in that case I would make a follow up that statically disallows a re-raise outside of
except
branches.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome, and thanks for working through the reasoning with me.