Recording this here as a known issue because it's come up in #187 and in private correspondence with @grassick:
JS Interpreter should provide a convenient mechanism for async native functions to throw errors.
At the moment it is possible to do using the following procedure:
Create an Error (or subclass) object by calling myInterpreter.createObject or .createObjectProto; call this error.
And of course ensure that myInterpreter.run() will get called again, to resume execution.
Step 4 will naturally always be the responsibility of the code which originally created the Interpreter instance to the embedder. Step 1 is likewise probably best left as a responsibility of the author of the native function. But Steps 2 and 3 are very much implementation details of the JS Interpreter (note that paused_ has a trailing underscore, so is supposed to be private!), so ought to be encapsulated.
One possible solution to this problem has been proposed in PR #178.
Recording this here as a known issue because it's come up in #187 and in private correspondence with @grassick:
JS Interpreter should provide a convenient mechanism for async native functions to throw errors. At the moment it is possible to do using the following procedure:
Error(or subclass) object by callingmyInterpreter.createObjector.createObjectProto; call thiserror.myInterpreter.unwind(Interpreter.Completion.THROW, error, undefined)myInterpreter.paused_ = falsemyInterpreter.run()will get called again, to resume execution.Step 4 will naturally always be the responsibility of the code which originally created the
Interpreterinstance to the embedder. Step 1 is likewise probably best left as a responsibility of the author of the native function. But Steps 2 and 3 are very much implementation details of the JS Interpreter (note thatpaused_has a trailing underscore, so is supposed to be private!), so ought to be encapsulated.One possible solution to this problem has been proposed in PR #178.