swiftwasm / swiftwasm/JavaScriptKit
Ask for Feedback: Make `JSObject` / `JSFunction` calls be `throws`
Nadie ha tomado este issue todavía.
- Lenguaje dominante
- Swift
- Estrellas
- 986
- Forks
- 76
- Merge medio
- 21 h 11 min
- PR fusionados (30 d)
- 4
Descripción
Every dynamic JS function calls can throw an exception, but the current JSObject and JSFunction are non-throws by default.
They can be throws by .throws or .throwing but it's still opt-in.
For example, if an exception is thrown during a JS function call but the call site in Swift side is not throws, the control unwinding wasm call frames without executing function epilogues even if there is do { } catch {} clause in Swift. And also in that case, defer blocks won't be called.
This behavior is quite tricky and unwinding wasm call frames without executing function epilogues can lead to memory and resource leak.
I'm going to introduce an API breaking change to make JSObject / JSFunction calls be throws in the next next release to improve the situation.
This change has a performance tradeoff as throws variants are typically a little bit slower than non-throwing variants. We should measure the amount of the penalty but it shouldn't be a big deal. We can make non throwing calls as an opt-in feature so that those who want best performance can satisfy their needs.
// Before
let foo = JSObject.global.document.getElementById!("foo")
let foo = try JSObject.global.document.throwing.getElementById!("foo")
// After
let foo = try JSObject.global.document.getElementById!("foo")
let foo = JSObject.global.document.nonthrowing.getElementById!("foo")
Let me know here if you have a strong objection 🙏 Thanks.
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.
Línea de trabajo
El issue menciona JSObject y JSFunction como las APIs afectadas, pero no proporciona ningún archivo ni punto de entrada de prueba. Revisa sus implementaciones de llamadas y el comportamiento existente de .throws/.throwing; después, mide el compromiso de rendimiento y define pruebas para llamadas que lanzan excepciones y que no las lanzan antes de decidir el cambio incompatible de la API.
Escrito por el modelo de indexación a partir del texto del issue.
Evaluación
- Stack tecnológico
- javascript, swift, wasm
- Área
- api
- Tipo de issue
- Nueva funcionalidad
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Estado de actividad
- Estancado
- Claridad
- Necesita aclaración
- Aptitud para principiantes
- 25/100