Chakra napi shim: throws from class constructors are swallowed (don't surface to JS)
Los mantenedores suelen responder en 1 día
@bghgary ya está trabajando en esto.
Desde el 9/6/2026.
Evaluación
Este issue todavía no se ha evaluado.
Descripción
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).
- Lenguaje dominante
- C++
- Estrellas
- 22
- Forks
- 23
- Merge medio
- 4 d 8 h
- PR fusionados (30 d)
- 3
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de BabylonJS/JsRuntimeHost
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
BabylonJS/JsRuntimeHost#234 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
BabylonJS/JsRuntimeHost#173 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 42/100
BabylonJS/JsRuntimeHost#241 · 3 comentarios ·
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
BabylonJS/JsRuntimeHost#228 ·
Los mantenedores suelen responder en 1 día
-
napi_unwrap does not reject objects that were never wrapped (V8 port faults, QuickJS port confuses types)Posiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 68/100
BabylonJS/JsRuntimeHost#226 ·
Los mantenedores suelen responder en 1 día
Todos los issues de BabylonJS/JsRuntimeHost
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
WebAssembly/binaryen#9207 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
godotengine/godot#124139 ·
Los mantenedores suelen responder en 1 día
-
Run CICD on any branch pushAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
ChicoState/autovalidate#195 ·