Chakra napi shim: throws from class constructors are swallowed (don't surface to JS)
@bghgary is already working on this.
Since Jun 9, 2026.
Assessment
This issue has not been assessed yet.
Description
On the Chakra backend, throwing a Napi::TypeError (or any Napi::Error) from a class constructor body — i.e. inside the function passed to Napi::ObjectWrap<T> / napi_define_class's callback — does not surface as a catchable JS exception. Instead the JS-side new MyClass() resolves to a half-constructed instance, so test code like expect(() => new (File as any)()).to.throw() silently fails.
This forces polyfills with required constructor arguments (WHATWG File, future Request, etc.) to either skip the WebIDL "missing required argument → TypeError" surface on Chakra, or omit the corresponding tests on Chakra.
Repro
class Foo : public Napi::ObjectWrap<Foo> {
public:
static Napi::Function Init(Napi::Env env) {
return DefineClass(env, "Foo", {});
}
Foo(const Napi::CallbackInfo& info) : Napi::ObjectWrap<Foo>(info) {
throw Napi::TypeError::New(info.Env(), "always throws");
}
};
In JS on Chakra: expect(() => new Foo()).to.throw() fails — no exception is thrown.
On V8 and JSC: throws as expected.
Current workaround
In Polyfills/File/Tests/UnitTests/Scripts/tests.ts (introduced by #169), tests that assert the constructor throws on missing/invalid arguments are commented out with a TODO pointing here. They should be re-enabled atomically when this is fixed.
Likely root cause
The Chakra napi shim's ExternalCallback::Callback (in Core/Node-API/Source/js_native_api_chakra.cc) probably needs to translate env->last_exception into a JsRT exception via JsSetException before returning to the JsRT runtime when invoked in construct mode. The function-call path likely already does this; the constructor path appears not to.
Related
- JsRH#172 (separate JSC napi shim quirk).
- JsRH#169 (the PR that surfaced this).
- Dominant language
- C++
- Stars
- 22
- Forks
- 23
- Avg merge
- 6d 17h
- Merged PRs (30d)
- 5
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from BabylonJS/JsRuntimeHost
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
BabylonJS/JsRuntimeHost#234 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
BabylonJS/JsRuntimeHost#173 ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
BabylonJS/JsRuntimeHost#228 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 68/100
BabylonJS/JsRuntimeHost#226 ·
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 35/100
BabylonJS/JsRuntimeHost#219 ·
All issues in BabylonJS/JsRuntimeHost
Similar issues
-
enhancement
Difficulty 1/5 Under an hour Newbie friendliness 88/100
QuantStack/git2cpp#187 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
AXERA-TECH/ax-llm#77 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
games-on-whales/wolf#509 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100