Skip to content
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

Order of operations, when to throw or silently do nothing? #16

Open
erights opened this issue Dec 1, 2024 · 1 comment
Open

Order of operations, when to throw or silently do nothing? #16

erights opened this issue Dec 1, 2024 · 1 comment

Comments

@erights
Copy link
Collaborator

erights commented Dec 1, 2024

Originally:

Should trying to write data in an immutable ArrayBuffer via a TypedArray element set throw, even though trying to write out-of-bounds or to a detached ArrayBuffer does not?

Should TypedArray write methods (copyWithin, fill, reverse, set, etc.) throw when their backing ArrayBuffer is immutable but the targeted range is zero-length? If so, how early or late in the algorithm? The methods currently inspect arguments after ValidateTypedArray.

Similarly,

  • How early or late in SetViewValue against an immutable ArrayBuffer should an exception be thrown? It currently inspects arguments before IsViewOutOfBounds.

  • Likewise for abstract operations such as ArrayBufferCopyAndDetach (which currently checks IsSharedArrayBuffer, then newLength, then IsDetachedBuffer).

  • And also for Atomics functions.

@erights
Copy link
Collaborator Author

erights commented Dec 1, 2024

To be driven by implementor feedback.

But my general inclination is: when in doubt, throw.

Moddable XS implementation throws.

Looking for further implementation feedback, both regarding throwing, and any other observable order-of-operation questions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant