Manejo de errores con try/catch sin romper la UX

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`.

Mentalidad correcta: fallar de forma controlada

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).

Patrón base de try/catch

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 silencies errores críticos: registra contexto mínimo.
  • Devuelve estructuras consistentes (`ok/data/error`) para simplificar consumo.
  • Evita `catch` vacíos: ocultan problemas reales.
  • Si no puedes recuperarte, relanza (`throw`) con contexto.

Crear errores de dominio con throw

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 para limpieza y cierre

`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.

  • Úsalo para liberar recursos o restaurar estado de interfaz.
  • No depende de que exista error para ejecutarse.
  • Evita side-effects complejos en `finally`.
  • Comprueba estado final en pruebas para evitar bloqueos de UI.

Traducir errores técnicos a mensajes de UX

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.

  • Mensaje UX: claro, breve y orientado a siguiente paso.
  • Log técnico: incluye contexto (`modulo`, `accion`, `id`).
  • No expongas internals sensibles en mensajes de interfaz.
  • Diferencia errores recuperables de errores críticos.
JavaScript
22

Manejo de errores con try/catch sin romper la UX

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

📘 Teoría

Mentalidad correcta: fallar de forma controlada

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).

1

Prevención

2

Contención

3

Comunicación

4

Recuperación

Patrón base de try/catch

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 silencies errores críticos: registra contexto mínimo.
  • Devuelve estructuras consistentes (`ok/data/error`) para simplificar consumo.
  • Evita `catch` vacíos: ocultan problemas reales.
  • Si no puedes recuperarte, relanza (`throw`) con contexto.

Crear errores de dominio con throw

No todo error viene del motor; muchos vienen de reglas de negocio.

1

`throw` te permite detener el flujo cuando una condición invalida una operación (por ejemplo, email vacío o cantidad negativa).

2

Usar errores con mensajes concretos mejora depuración y facilita mapear respuesta de UI según tipo de fallo.

finally para limpieza y cierre

`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.

  • Úsalo para liberar recursos o restaurar estado de interfaz.
  • No depende de que exista error para ejecutarse.
  • Evita side-effects complejos en `finally`.
  • Comprueba estado final en pruebas para evitar bloqueos de UI.

Traducir errores técnicos a mensajes de UX

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.

  • Mensaje UX: claro, breve y orientado a siguiente paso.
  • Log técnico: incluye contexto (`modulo`, `accion`, `id`).
  • No expongas internals sensibles en mensajes de interfaz.
  • Diferencia errores recuperables de errores críticos.

🧪 Aprende probando

Ejemplo Ejemplo guiado: parseo de API con salida segura Intenta parsear una respuesta JSON y devuelve una estructura consistente para la UI.
Ejemplo Ejemplo guiado: validación de formulario Lanza un error de dominio cuando la entrada no cumple reglas mínimas.
Ejemplo Demo interactiva: ejecutor seguro Introduce JSON y observa cómo la interfaz responde sin romperse cuando hay error.

🏁 Retos

Reto Reto 1: parsearUsuarioSeguro Crea una función que intente parsear JSON de usuario y devuelva resultado controlado.
Reto Reto 2: validarTotal con throw y finally Implementa un flujo con validación, captura de error y limpieza final de estado.

¿Qué es esto?

Soy Cristian Eslava y a veces hago webs para procrastinar yo y vosotros. culTest

La hice en febrero de 2026 para facilitar el aprendizaje de mis alumnos. La idea es aprender desarrollo web practicando y que el proyecto siga creciendo con nuevos temas, tests y retos.

Está inspirada en MDN, W3Schools, CodePen, Manz y muchos otros sitios de documentación sobre desarrollo web. Quería combinar teoría útil, ejemplos ejecutables, retos y el sistema de tests que ya tenía en culTest. culTest

Si te gustó, si no te gustó o si quieres escribirme, puedes hacerlo en cristianeslava@gmail.com