Volver a la lista

Manejo de excepciones en el frontend: lo más importante, pero a menudo se descuida.

Explica la importancia de la gestión de excepciones en el frontend, los límites de error (Error Boundaries) para evitar pantallas en blanco y los patrones de manejo de errores.

Intermedio
|
5min
|
Verificado (2026-07)
Progreso0/48 (0%)

Manejo de excepciones en el frontend: lo más importante y lo que menos se hace

Al finalizar este tema

Comprenderá por qué es fácil omitir el manejo de excepciones en el frontend y cómo proporcionar retroalimentación significativa en lugar de una pantalla en blanco.


En el backend, si hay un error, aparece un 500

En el backend, si ocurre un error, el servidor responde con un código 500. Se registra un seguimiento de pila en los registros. El desarrollador revisa los registros y lo corrige. El usuario ve un mensaje que dice "inténtelo de nuevo más tarde".

¿Y en el frontend? La pantalla se vuelve blanca. No aparece nada. Si el usuario actualiza la página, sigue viendo la misma pantalla en blanco. Tampoco hay mensajes de error.

Esto ocurre porque, si se produce un error no manejado en JavaScript, todo el árbol de componentes falla. En React, el error de un solo componente puede provocar que toda la aplicación deje de funcionar.


¿Por qué no se hace?

La razón por la que no se manejan las excepciones es simple: "por ahora funciona".

Durante el desarrollo, siempre hay datos disponibles, la red siempre está activa y los usuarios solo ingresan datos válidos. Como no surgen errores, no se implementa el manejo de errores.

Sin embargo, el entorno real del usuario es diferente:

  • La API devuelve un 503
  • Los datos son null
  • La conexión de red se interrumpe y se restablece
  • Las extensiones del navegador modifican el DOM

Si ocurre cualquiera de estos casos, TypeError: Cannot read properties of undefined falla y la pantalla se vuelve blanca.


Básico: try-catch en las llamadas a la API

El punto más común donde ocurren errores es en las llamadas a la API:

javascript
// Código peligroso
const res = await fetch("/api/users");
const data = await res.json();
setUsers(data.users);  // Falla si data es null

// Código seguro
try {
  const res = await fetch("/api/users");
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  const data = await res.json();
  setUsers(data.users ?? []);
} catch (err) {
  setError("No se pudo cargar la lista de usuarios.");
}

Lo fundamental es qué mostrar al usuario cuando se produce un error. En lugar de una pantalla en blanco, debería haber al menos un botón que diga "Volver a intentarlo".


React Error Boundary

Las llamadas a la API se pueden gestionar con try-catch, pero los errores que se producen durante la renderización no se pueden gestionar. Si un componente genera un error mientras se está renderizando, toda la aplicación de React se detiene.

Lo que gestiona estos errores es el Error Boundary:

javascript
class ErrorBoundary extends React.Component {
  state = { hasError: false };

  static getDerivedStateFromError(error) {
    return { hasError: true };
  }

  render() {
    if (this.state.hasError) {
      return <p>Se produjo un problema. Actualiza la página.</p>;
    }
    return this.props.children;
  }
}
javascript
<ErrorBoundary>
  <UserProfile />
</ErrorBoundary>

Si se produce un error en UserProfile, en lugar de detenerse toda la aplicación se muestra el mensaje "Se ha producido un problema". El resto de la aplicación sigue funcionando con normalidad.

Si aplicas un límite de errores (Error Boundary) a cada página, un error en una página no afectará a las demás.


La carga y los estados vacíos también son casos especiales.

No solo los errores son casos especiales. También hay que gestionar los casos en los que los datos aún no han llegado o están vacíos.

javascript
function UserList({ users }) {
  if (users === undefined) return <Spinner />;      // Cargando
  if (users.length === 0) return <p>No hay usuarios.</p>;  // Estado vacío
  return users.map(u => <UserCard key={u.id} user={u} />);
}

Cargando, Estado vacío, Error, Éxito — Gestionar estos cuatro estados es fundamental para el manejo de excepciones en el frontend.

Si no se gestionan, los usuarios no podrán distinguir si una pantalla en blanco indica que se está cargando, que no hay datos o que se ha producido un error.


Lista de verificación para el trabajo diario

Al revisar el manejo de excepciones en el frontend, se pueden hacer las siguientes preguntas:

  • ¿Qué ve el usuario cuando falla la API?
  • ¿Se bloquea la pantalla si los datos son null?
  • ¿Qué ocurre cuando se pierde la conexión de red?
  • ¿Qué se muestra durante la carga?
  • ¿Qué se muestra cuando los datos están vacíos?

Si la respuesta a estas preguntas es "pantalla en blanco" o "no lo sé", significa que falta el manejo de excepciones.


Concepto clave

Los errores no gestionados en el frontend provocan una pantalla en blanco. Los límites de error capturan los errores de renderizado y evitan que falle toda la aplicación. La clave está en gestionar los cuatro estados: carga, estado vacío, error y éxito.

💬 Preguntas y comentarios

0 comentarios

Puedes publicar sin iniciar sesión. Los comentarios de invitados no pueden editarse ni eliminarse después.

0/2000

Cargando...