Manejo de errores en Promises y async/await

Objetivo

Cada promesa rechazada se maneja allí donde se puede hacer algo útil con ella o se expone como un fallo registrado con contexto. Ninguna se descarta en silencio y ninguna detiene el proceso de forma inesperada.

Requisitos previos

Una función async siempre devuelve una promesa: un throw en su interior se convierte en un rechazo, y await sobre una promesa rechazada vuelve a lanzar el error en ese punto (MDN). Conozca la política del entorno de ejecución para los rechazos que nadie maneja: los navegadores emiten un evento unhandledrejection en window; Node.js, con el valor predeterminado --unhandled-rejections=throw, lo eleva como excepción no capturada, lo que termina el proceso si no se maneja.

Pasos

1. Para cada llamada con await, decida si quien llama puede recuperarse (reintentar, usar una alternativa, mostrar un mensaje). Solo en ese caso envuélvala: try { data = await load(); } catch (e) { ... } alrededor de las sentencias que pueden fallar, no de toda la función.
2. Si no puede recuperarse, deje que el rechazo se propague o vuelva a lanzar un error más específico que conserve el original adjunto (new Error("profile load failed", { cause: e })) para que la pila de llamadas no se pierda.
3. Nunca deje una promesa sin gestionar. Una llamada sin await, return ni .catch es un rechazo del que nadie se hace cargo; active una regla de lint que marque las promesas sin await y corrija cada aviso.
4. No mezcle cadenas .then() y await en una misma función; un return olvidado dentro de .then oculta el fallo al try que lo rodea.
5. Para el trabajo concurrente, elija de forma deliberada: Promise.all cuando un solo fallo invalida todo el lote, Promise.allSettled cuando los resultados parciales son útiles. En ambos casos cada promesa de entrada recibe un manejador, de modo que los fallos posteriores no quedan sin manejar.
6. Registre un manejador de último recurso que registre el motivo y el origen de la promesa: window.addEventListener("unhandledrejection", ...) en el navegador, process.on("unhandledRejection", ...) en Node.js. En un proceso de servidor, registre el error y termine en lugar de continuar con un estado desconocido.
7. Rechace siempre con instancias de Error; una cadena rechazada no tiene traza de pila ni cause.
8. Escriba una prueba para cada ruta de fallo documentada que verifique el tipo y el mensaje del rechazo.

Resultado esperado

Los fallos aparecen una sola vez, en una única línea de log con contexto, en la capa que decidió qué hacer con ellos. Las ejecuciones de CI no muestran advertencias de rechazos no manejados.

Límites y base de verificación

La cancelación no es una condición de error; un AbortError de un fetch cancelado debe reconocerse e ignorarse, no notificarse. El comportamiento descrito se basa en la documentación citada; no se afirma ninguna medición.