Aprende a detectar, capturar y comunicar errores de forma profesional usando `try/catch`, `throw` y `finally`, manteniendo una interfaz estable para la persona usuaria.
Los errores no son excepciones raras: son parte normal del ciclo de vida de cualquier aplicación real.
La diferencia entre una app frágil y una robusta está en cómo gestiona fallos de red, datos corruptos o entradas inválidas.
`try/catch` te permite controlar el impacto técnico; una buena UX de error evita que la persona usuaria se quede bloqueada.
Objetivo de esta lección: construir flujos resistentes, con mensajes útiles y depuración clara sin ocultar problemas reales.
No se trata de evitar todos los errores, sino de diseñar respuestas seguras.
Un error sin control puede romper una vista completa. Un error bien gestionado informa, registra contexto y permite continuar con degradación razonable.
Piensa en tres niveles: usuario (mensaje claro), desarrollador (log útil) y sistema (estado coherente tras el fallo).
Encierra solo el bloque con riesgo real y maneja el error con contexto.
`try` ejecuta el código potencialmente peligroso. Si ocurre un error, salta a `catch` con el objeto `error`.
Evita envolver funciones enormes en un único `try`; divide por pasos para localizar causa y facilitar recuperación.
No todo error viene del motor; muchos vienen de reglas de negocio.
`throw` te permite detener el flujo cuando una condición invalida una operación (por ejemplo, email vacío o cantidad negativa).
Usar errores con mensajes concretos mejora depuración y facilita mapear respuesta de UI según tipo de fallo.
`finally` se ejecuta siempre, haya error o no.
Es ideal para apagar loaders, cerrar recursos temporales o restaurar banderas de estado que la UI necesita para no quedar bloqueada.
Evita poner lógica de negocio principal en `finally`; úsalo para tareas de cierre predecibles.
La persona usuaria no necesita stack traces; necesita acción clara.
Mapea errores técnicos a mensajes accionables: reintentar, revisar datos o contactar soporte según gravedad.
Mantén detalle técnico en logs, pero muestra en UI textos breves y comprensibles para no generar ansiedad ni confusión.
Aprende a detectar, capturar y comunicar errores de forma profesional usando `try/catch`, `throw` y `finally`, manteniendo una interfaz estable para la persona usuaria.
Código del tema: try/catch · throw · finally · Error
No se trata de evitar todos los errores, sino de diseñar respuestas seguras.
Un error sin control puede romper una vista completa. Un error bien gestionado informa, registra contexto y permite continuar con degradación razonable.
Piensa en tres niveles: usuario (mensaje claro), desarrollador (log útil) y sistema (estado coherente tras el fallo).
Encierra solo el bloque con riesgo real y maneja el error con contexto.
`try` ejecuta el código potencialmente peligroso. Si ocurre un error, salta a `catch` con el objeto `error`.
Evita envolver funciones enormes en un único `try`; divide por pasos para localizar causa y facilitar recuperación.
function parsearConfiguracion(texto) {
try {
const config = JSON.parse(texto);
return { ok: true, data: config };
} catch (error) {
console.error('[config] JSON inválido:', error.message);
return { ok: false, error: 'No se pudo leer la configuración.' };
}
}
console.log(parsearConfiguracion('{"tema":"oscuro"}'));
console.log(parsearConfiguracion('{tema:oscuro}'));No todo error viene del motor; muchos vienen de reglas de negocio.
`throw` te permite detener el flujo cuando una condición invalida una operación (por ejemplo, email vacío o cantidad negativa).
Usar errores con mensajes concretos mejora depuración y facilita mapear respuesta de UI según tipo de fallo.
function crearPedido(total) {
if (total <= 0) {
throw new Error('El total debe ser mayor que cero.');
}
return { id: Date.now(), total };
}
try {
console.log(crearPedido(-5));
} catch (error) {
console.error('[pedido]', error.message);
}`finally` se ejecuta siempre, haya error o no.
Es ideal para apagar loaders, cerrar recursos temporales o restaurar banderas de estado que la UI necesita para no quedar bloqueada.
Evita poner lógica de negocio principal en `finally`; úsalo para tareas de cierre predecibles.
let cargando = false;
async function cargarDatos() {
cargando = true;
try {
// Simulación de trabajo
const datos = ['curso', 'leccion'];
return datos;
} catch (error) {
console.error('[carga]', error.message);
return [];
} finally {
cargando = false;
console.log('loader apagado');
}
}La persona usuaria no necesita stack traces; necesita acción clara.
Mapea errores técnicos a mensajes accionables: reintentar, revisar datos o contactar soporte según gravedad.
Mantén detalle técnico en logs, pero muestra en UI textos breves y comprensibles para no generar ansiedad ni confusión.