tipos - parse html javascript
¿Prometerá Javascript ES6 el soporte ''hecho'' de la API? (3)
Por ejemplo
p = new Promise(function (resolve, reject) {
throw ''err'';
});
p.done();
En la mayoría de las librerías de Polyfill prometidas, el hecho arrojará un error y la ejecución actual se cerrará.
Pero si usamos p.then() , nada sucederá. El error es tragado por la promesa. Si usamos p.catch , no tenemos manera de salir de la ejecución actual. Quiero lograr algo como:
try {
// something
} catch (err) {
if (check(err)) {
throw err;
}
}
No.
.done probable que .done no solo no sea compatible con las futuras versiones de la especificación, sino que también es innecesario. Citando de los hilos de Mariusz vinculados a:
Domenico
todavía es propenso a errores: si se equivoca y no sigue la regla ni una sola vez, puede silenciar un error para siempre.
Mark Miller (quien fue pionero en el concepto de promesas):
Tenga en cuenta que los refs débiles, con suerte en ES7, nos proporcionarán una de las herramientas de diagnóstico que necesitamos para cerrar esta brecha. Usando deb-refs, si una promesa rechazada se recopila sin haber notificado a ningún manejador, podemos arreglar que esto genere un diagnóstico. La implementación de la promesa tendría que mantener la razón en el ejecutor de la promesa (manejador post-mortem gc), para que tenga el diagnóstico para informar después de descubrir que la promesa ha sido rechazada.
Yehuda Kats en el controlador de errores de RSVP:
El enfoque que estamos tomando en RSVP es instalar un monitor de promesa no manejado que se lanza de forma predeterminada.
Puede optar por una promesa particular de este comportamiento adjuntando un controlador de fallas noop, si sabe que adjuntará controladores asincrónicos de errores. Probablemente tendremos azúcar para esto (.undone: p)
En nuestra experiencia, es apropiado trasladar la carga de literalmente todos a personas que quieran adjuntar controladores asíncronos de errores.
Y, desde el repo real que precedió a la especificación, Domenic dijo:
el trabajo de done se realizará integrando la funcionalidad de seguimiento de rechazo no controlada en las herramientas de desarrollo. La mayoría de los TC39, por lo que entiendo, así como yo mismo, perciben eso como suficiente para que la especificación esté completa.
El comité de especificaciones no solo ignoró .done , sino que consideró que era innecesario y propenso a errores. Las nuevas bibliotecas de promesas modernas detectan automáticamente los rechazos no controlados, dos ejemplos de esto son Cuando promesas y Promesas de Bluebird que fueron pioneras en la idea.
.done es un artefacto, originado por el hecho de que el navegador no pudo detectar rechazos no controlados. La verdad es que es imposible detectarlos de manera determinista, pero para la gran mayoría de los casos es completamente posible.
No me crees Abre Firefox y juega con sus promesas nativas:
p = new Promise(function (resolve, reject) {
throw ''err'';
});
// Logs as error: Unhandled error: `err`
En pocas palabras, Firefox usa ganchos de recolección de basura para determinar que las promesas se desecharon en un estado no manejado y dispara un controlador de errores global que por defecto escribe en la pantalla.
Ahora, el problema es que las promesas nativas aún no son muy útiles, ya que en IE no existen y en Chrome aún no se implementó la detección de rechazo no gestionado, pero llegará y estará allí. Mientras tanto, puede usar una biblioteca compatible con ES6 como Bluebird que hará este seguimiento de rechazo por usted.
Si desea realizar un relleno múltiple (que recomiendo encarecidamente ): el relleno múltiple de torazaburo tiene algunos inconvenientes. Declara una propiedad enumerable en el prototipo de promesa y, por lo general, no es así como se diseñó la especificación. Se espera que las subclases de promesas se extiendan en lugar de aplicarles un parche al mono.
Así que en resumen:
- Espere a que las promesas nativas se estabilicen antes de usarlas; mientras tanto, puede usar bibliotecas que implementan la especificación como Bluebird. Cuando se estabilice, no tener
.doneno será un problema en absoluto. - Utilice patrones para detectar errores, por ejemplo, consulte el patrón del eliminador aquí.
- Utilice las herramientas de desarrollador cuando estén disponibles, los trazados de pila larga y la depuración asíncrona son grandes problemas. También tenga en cuenta que no debe lanzar cadenas si desea rastreos de pila significativos.
Buena suerte y feliz codificación.
La declaración actual de TC39 es que este problema puede y debe resolverse de forma nativa en los motores de navegador con herramientas de desarrollador. Es por eso que están enfrente de proporcionar done dentro de la API nativa.
De hecho, es una decisión controvertida, vea los siguientes enlaces para discusiones sobre ese tema:
https://github.com/domenic/promises-unwrapping/issues/19
http://mozilla.6506.n7.nabble.com/Where-d-Promise-done-go-td281461.html
No, AFAIK done no es parte de la especificación. Para imitar su comportamiento, debe lanzar la excepción en el siguiente tick, fuera del alcance de la cadena de promesas:
p.catch(function(e) {
setTimeout(function() { throw e; });
});
Esto es esencialmente cómo implementan las bibliotecas done . Ver extracto de documentos Q:
Como
then, pero ... la razón de rechazo resultante se lanza como una excepción en un giro futuro del bucle de eventos .
Implementado done usted mismo
Si desea implementar la semántica aproximada de done como se entiende normalmente, entonces algo como:
Promise.prototype.done = function(onFulfilled, onRejected) {
this
.then(onFulfilled, onRejected)
.catch(function(e) {
setTimeout(function() { throw e; });
})
;
};
Configurando un manejador de errores
Si desea tener la oportunidad de manejar estos errores usted mismo, puede configurar un controlador de errores:
Promise.onError = function(e) {
console.log("The sky is falling", e);
throw e;
};
A continuación, invoque el controlador en el siguiente tick:
Promise.prototype.done = function(onFulfilled, onRejected) {
this
.then(onFulfilled, onRejected)
.catch(function(e) {
setTimeout(Promise.onError || function() { throw e; }, 1, e);
})
;
};