Me gusta async/await pero no entiendo por qué tenemos que envolver nuestro await en un bloque try/catch para detectar errores. ¿Por qué no hacer que la espera devuelva algún tipo de objeto de error estandarizado y luego lo probamos?
Entonces podríamos hacer algo como:
let results = await somePromise(); results?.err ? doSomething() : handleErr()El objetivo de async/await es permitir que el código asíncrono/basado en promesas se escriba de una manera más similar al código síncrono. El código síncrono usa try/catch para manejar las excepciones, por lo que, según el principio de menor sorpresa , await también debería hacerlo.
El manejo de errores depende del autor. Si no controla algún código que lanza, y quiere que no lo haga, envuélvalo con algo que atrapa pero no lanza. En su propio código, debe sentirse libre de devolver objetos de error en lugar de lanzarlos.
Solo tenga en cuenta que otros esperan lanzar / atrapar como una convención.
// this one throws errors import fnNotControlledByMe from 'external_lib' // use this one as a wrapper, and don't throw // this and any other function you write can opt not to throw async function fnControlledByMe() { try { let results = fnNotControlledByMe(); return results; } catch (err) { return { err }; } } async function opFunction() { let results = await fnControlledByMe(); results?.err ? doSomething() : handleErr() }¿Por qué no hacer que la
awaitdevuelva algún tipo de objeto de error estandarizado y luego lo probamos?
Porque eso supone que siempre desea probar el error. En muchos (¡la mayoría!) de los casos no lo hace, quiere dejar que la excepción se propague. Esto conduce a una gran cantidad de código repetitivo (como el patrón de devolución de llamada del nodo con parámetros de error ), errores ignorados por programadores ignorantes (no conscientes) y riesgos de refactorización.
Como señaló @SeanSutherland en su respuesta, esto también hace que el manejo de errores asíncronos sea simétrico al manejo de errores síncronos, con las mismas expectativas .