feat(pass-style): generalize passable errors, throwables #2223
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
erights
force-pushed
the
markm-to-throwable
branch
2 times, most recently
from
1402c8a
to
dd4b963
Compare
1 task
erights
added a commit
that referenced
this pull request
May 6, 2024
closes: #XXXX refs: #2223 ## Description Modest step towards #2223 , - bringing all the intended safety: the exo boundary only throws throwables, and that `callWhen` async exo methods only reject with throwable reasons. - but with less flexibility: the definition of passable errors and throwables is narrower than it need be. ### Security Considerations This is one of three necessary steps towards having the exo boundaries become the new intravat defensive security boundary, rather than treating every object boundary as a potential defensive security boundary. The rationale for this step is that the throw-control-path is too hard for reviewers to pay full attention to, so we wish to prevent caps from leaking over the exo boundary via the throw path. (E prevented caps from escaping via throws in general, but we're not in a position to be able to enforce that in general within Hardened JS.) The other two steps are - Converting uses of `Far` for making far objects into making exos. - Addressing the leakage of promise settlements across exo boundaries due to the inability to synchronously enforce such a constraint on a promise passed through the boundary. ### Scaling Considerations Given that the exceptional pathways (throws and rejects) are only used for low frequency exceptional conditions, or at least exceptional conditions whose speed we don't care about, making this slow path a tiny bit slower should be inconsequential. Indeed, I expect the overall impact to be unmeasurable. (But we won't know until we measure!) ### Documentation Considerations This restriction on what can be throws across the exo boundary (or for exo async `callWhen` methods, what can be used as a rejection reason) needs to be documented. But it should not affect any normal code, and so documents an edge case. ### Testing Considerations tests included ### Compatibility Considerations If there are currently any throws or rejects that violate these constraints (likely) where other code depends on these violations (unlikely), then we have a compat problem. ### Upgrade Considerations None. - ~[ ] Includes `*BREAKING*:` in the commit message with migration instructions for any breaking change.~ - [x] Updates `NEWS.md` for user-facing changes.
erights
force-pushed
the
markm-to-throwable
branch
from
76c3c58
to
d06c83b
Compare
Merged
erights
force-pushed
the
markm-to-throwable
branch
3 times, most recently
from
a6df983
to
0d49be1
Compare
erights
force-pushed
the
markm-to-throwable
branch
from
0d49be1
to
b450373
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Just placeholder for now. Not yet expected to work or almost work.
closes: #XXXX
refs: #XXXX
Description
Security Considerations
Scaling Considerations
Documentation Considerations
Testing Considerations
Compatibility Considerations
Upgrade Considerations
*BREAKING*:in the commit message with migration instructions for any breaking change.NEWS.mdfor user-facing changes.