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.

Sign up for GitHub

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

Jump to bottom

Support JS errors #37

Closed
j-f1 opened this issue Aug 16, 2020 · 1 comment
Closed

Support JS errors #37

j-f1 opened this issue Aug 16, 2020 · 1 comment
Labels
enhancement New feature or request

Comments

@j-f1
Copy link
Member

j-f1 commented Aug 16, 2020

Currently, making a call from Swift to JS that results in an error being thrown on the JS side will leave the code in a strange state. I’m not sure if wasm is able to recover from this. Maybe there could be an additional parameter passed to the JS function that allows it to send back a JSObjectRef pointing to a thrown error (kind of like Objective-C!).

Since we don’t have type info (which could be partially alleviated by #21) we have to assume that every property access and function call potentially throws. Not sure what the proper balance is here.

We’d also need a way to bridge errors over to the Swift side. Perhaps this could be somewhat type-safe, with distinct subclasses for common/host-provided errors and a generic JSError class for everything else.

It would also be good to make JSClosures able to throw, then wrap those errors into a SwiftError on the JS side.
@j-f1 j-f1 added the enhancement New feature or request label Aug 16, 2020
@MaxDesiatov
Copy link
Contributor

Closing as resolved in #102. Feel free to reopen if anything is missing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@MaxDesiatov @j-f1