JavaScript
Explica dónde manejar un error, cuándo dejarlo propagarse y cómo recuperar, traducir, añadir contexto, limpiar recursos o registrar sin duplicar fallos.
Un error debería manejarse en la capa que puede tomar una decisión útil.
origen del fallo
↓
propagación
↓
frontera que entiende el contexto
↓
recuperar, traducir, reportar o finalizarfunction loadProducts() {
return repository.findAll();
}Si findAll lanza y loadProducts no captura, el error continúa hacia su consumidor.
No necesitas escribir:
try {
return repository.findAll();
} catch (error) {
throw error;
}La versión sin try comunica lo mismo y conserva el stack sin ruido adicional.
Una capa debería capturar cuando puede:
Si no puede hacer ninguna, normalmente debe dejarlo propagarse.
try {
return readFromCache(key);
} catch (error) {
if (error instanceof CacheUnavailableError) {
return readFromDatabase(key);
}
throw error;
}La capa conoce una alternativa válida.
Un fallback debe conservar el significado. Retornar [] ante un fallo de autorización no significa “no hay datos”.
try {
return repository.findById(productId);
} catch (cause) {
throw new ProductQueryError(
"Product lookup failed",
{
productId,
cause,
},
);
}El servicio no obliga a sus consumidores a conocer detalles del driver de base de datos.
La traducción debe conservar la causa y aportar una abstracción mejor, no cambiar un error específico por otro más vago.
try {
return parseOrder(payload);
} catch (cause) {
throw new InvalidOrderPayloadError(
"Incoming order payload is invalid",
{
requestId,
cause,
},
);
}El contexto útil responde preguntas como:
No agregues datos sensibles.
Antipatrón:
repository log
service log
controller log
middleware log
monitoring logEl mismo error genera cinco eventos y parece que ocurrieron cinco fallos.
Una estrategia común:
cause o propiedades.La frontera puede ser:
Error interno:
{
code: "REPOSITORY_UNAVAILABLE",
message: "Connection timed out after 3000 ms",
cause: error,
}Respuesta al usuario:
{
code: "PRODUCTS_UNAVAILABLE",
message: "No pudimos cargar los productos.",
}No devuelvas automáticamente stack traces, consultas, rutas internas o credenciales.
Para una operación donde el fallo forma parte del flujo cotidiano:
function authenticate(credentials) {
if (!matches(credentials)) {
return {
success: false,
reason: "INVALID_CREDENTIALS",
};
}
return {
success: true,
user,
};
}El consumidor debe tratar ambos resultados.
Para un fallo inesperado de infraestructura:
throw new AuthenticationServiceError(
"Authentication service is unavailable",
{ cause },
);No conviertas todos los resultados esperados en excepciones ni todos los fallos inesperados en false.
try {
await saveOrder(order);
} catch (error) {
console.log(error);
}
return { success: true };La función afirma éxito aunque guardar falló.
Opciones coherentes:
Un reintento puede ayudar con fallos transitorios:
No suele resolver:
Antes de reintentar pregunta:
async function retry(operation, {
attempts = 3,
shouldRetry,
}) {
let lastError;
for (let attempt = 1; attempt <= attempts; attempt++) {
try {
return await operation();
} catch (error) {
lastError = error;
if (
attempt === attempts ||
!shouldRetry(error)
) {
throw error;
}
}
}
throw lastError;
}La estrategia temporal se completará en asincronía.
await saveOrder(order);
await sendConfirmation(order);Si la segunda falla, la orden puede estar guardada sin correo.
Eso no es necesariamente un fracaso total. El diseño puede:
Las excepciones no definen por sí solas atomicidad.
const resource = openResource();
try {
return useResource(resource);
} finally {
resource.close();
}La capa puede limpiar sin capturar ni modificar el error.
Navegadores y runtimes suelen permitir observar errores no capturados y rechazos no manejados.
Esos handlers sirven como última red para:
No sustituyen manejo local. En ese punto quizá ya no exista una forma segura de continuar la operación.
Con await:
try {
const product = await loadProduct();
} catch (error) {
handle(error);
}Sin await, el try no espera el resultado:
try {
loadProduct();
} catch {
// No maneja el rechazo futuro.
}La promesa debe retornarse, esperarse o recibir un .catch.
Repositorio:
async function findProduct(id) {
try {
return await database.products.find(id);
} catch (cause) {
throw new RepositoryError(
"Product query failed",
{ cause, entityId: id },
);
}
}Servicio:
async function requireProduct(id) {
const product = await findProduct(id);
if (!product) {
throw new ProductNotFoundError(id);
}
return product;
}Frontera HTTP:
async function handleRequest(request) {
try {
const product = await requireProduct(
request.params.id,
);
return json(product, 200);
} catch (error) {
reportError(error, {
requestId: request.id,
});
return toHttpResponse(error);
}
}Cada capa aporta algo distinto y la traza completa se registra una vez.
¿Qué problema hay en este fallback?
try {
return await loadPrivateOrders();
} catch {
return [];
}Convierte cualquier fallo —incluido un problema de permisos, conexión o programación— en “no existen órdenes”. El fallback cambia el significado de la información y oculta la causa. Solo sería válido para una categoría concreta que realmente permita esa alternativa.
Debugging explica cómo observar la ejecución y localizar la causa real de un comportamiento incorrecto.