Skip to content

Conversation

@bnoordhuis
Copy link
Collaborator

Instead of trying to detect upfront if an object can be serialized, just do it and see if it throws a DataCloneError.

Unexpected DataCloneErrors were of course already being handled but the new approach does it in a centralized and generic manner.

Failed serialization now passes an object with a single "error" string property back to Ruby land.

Fixes the failing test from #329

Instead of trying to detect upfront if an object can be serialized,
just do it and see if it throws a DataCloneError.

Unexpected DataCloneErrors were of course already being handled but
the new approach does it in a centralized and generic manner.

Failed serialization now passes an object with a single "error" string
property back to Ruby land.

Fixes the failing test from rubyjs#329
@SamSaffron
Copy link
Collaborator

I love that it is simpler, it remains a breaking change vs old behavior which would handle partial clones but I think this is probably ok, when we release this we can do a major version bump, will try this on Discourse today

@SamSaffron SamSaffron merged commit 394980b into rubyjs:main Jan 9, 2025
18 of 25 checks passed
@bnoordhuis bnoordhuis deleted the fix329 branch January 9, 2025 20:16
bnoordhuis added a commit to bnoordhuis/mini_racer that referenced this pull request Mar 13, 2025
Instead of trying to detect upfront if an object can be serialized,
just do it and see if it throws a DataCloneError.

Unexpected DataCloneErrors were of course already being handled but
the new approach does it in a centralized and generic manner.

Failed serialization now passes an object with a single "error" string
property back to Ruby land.

Fixes the failing test from rubyjs#329
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

Successfully merging this pull request may close these issues.

2 participants