Estoy trabajando en un proyecto mecanografiado que se basa en gran medida en la devolución de llamada. En este momento estoy trabajando en una clase y tuve que escribir algunos métodos nuevos usando otros métodos. Así que prometí los métodos que necesitaba y escribí los métodos con try/catch + async/await. Pero los métodos que escribí aún toman una devolución de llamada como parámetro y la promesa que devuelven se resuelve como nula, para poder ser utilizada por el resto del proyecto.
Estaba pensando que incluso mejor sería tratar de hacer que estos nuevos métodos sean compatibles tanto con las devoluciones de llamada como con las promesas, es decir, llamando a la devolución de llamada si se aprobó, pero también devolviendo las cosas que se pasarían a la devolución de llamada para que pudieran usarse. manera en el futuro, como parte de una función basada en devolución de llamada o una cadena de promesa/espera asíncrona.
Estoy confundido acerca de cuál debería ser el tipo de retorno en las anotaciones de tipo. Digamos que el método es obtener un usuario de la base de datos. No quiero lanzar dentro de este método porque el proyecto que lo rodea se basa en la estructura de devolución de llamada (err, data) , por lo que los errores lanzados no se detectarían. Así que tengo que devolver algo, pero no estoy seguro de las anotaciones de tipo. Decir que el tipo de retorno es User | Error ¿ User | Error parece incorrecto? Luego, las funciones de llamada tendrían que verificar el tipo que se devolvió en tiempo de ejecución, ¿verdad?
¿Cómo se deben manejar los errores sin tirar?
¿Conoces las Promesas rechazadas?
La forma idiomática de manejar los errores de una API de Promise es con rechazos de Promise, de modo que su promesa devuelta se cumpla con un Usuario o se rechace con un Error . Esto permite que los errores propaguen el estilo try/catch a través de cadenas de promesas. De la misma manera que llamaría a la devolución de llamada con un err en una función de estilo de devolución de llamada, puede return Promise.reject(err) ( docs ) o throw err desde una función async o then controlador; no hay mucha diferencia entre ellos .
En lo que respecta a TypeScript, no puede ni debe escribir específicamente el Error en el valor de retorno : se supone que todas las Promesas pueden ser rechazadas y que el motivo del rechazo puede ser del tipo any . Creo que es idiomático que el motivo de rechazo sea un error, pero al igual que la declaración de throw en JavaScript, puede ser fácilmente una cadena o un número.
Ver también: