Errores y programación defensiva · Lenguaje de marcas

Hoy · Hoja de ruta

1. Aprende: Cómo se lanza, se captura y se trata un error.
2. Haz: Protege tus funciones de las entradas que no esperas.
3. Comprueba: Tu programa falla de forma clara en vez de dar un resultado falso.

Antes de empezar · 5 minutos, sin apuntes

¿Qué le pasa a valorAlmacen si un producto no tiene precio?
¿Qué es peor: que el programa se pare, o que devuelva un número equivocado?
¿De dónde vienen los datos en los que menos confías?

Lanzar un error

function aplicarDescuento(precio, porcentaje) {
  if (typeof precio !== "number" || Number.isNaN(precio)) {
    throw new TypeError("El precio debe ser un número");
  }
  if (porcentaje < 0 || porcentaje > 100) {
    throw new RangeError("El porcentaje debe estar entre 0 y 100");
  }
  return precio * (1 - porcentaje / 100);
}

throw detiene la función ahí mismo. Es mejor que devolver null en silencio: quien llama se entera del problema en el momento en que ocurre y no tres funciones más tarde.

Capturar

try {
  const catalogo = JSON.parse(textoRecibido);
  console.log(catalogo.length);
} catch (error) {
  console.error(`No se pudo leer el catálogo: ${error.message}`);
} finally {
  console.log("Intento terminado");
}

try ejecuta, catch recibe el error si lo hay, finally se ejecuta pase lo que pase.

Un catch vacío es peor que ningún catch

Capturar un error y no hacer nada con él —ni registrarlo, ni avisar, ni reintentar— convierte un fallo ruidoso en uno invisible. El programa continúa con datos que no tiene, y el problema aparecerá más adelante, en un sitio que no tiene nada que ver.

Captura solo lo que sabes tratar. Lo que no sepas tratar, déjalo subir.

Validar en el borde

export function crearProducto(datos) {
  const errores = [];

  if (!datos.nombre?.trim()) errores.push("El nombre es obligatorio");
  const precio = Number(datos.precio);
  if (Number.isNaN(precio) || precio < 0) errores.push("Precio inválido");
  const stock = Number.parseInt(datos.stock, 10);
  if (!Number.isInteger(stock) || stock < 0) errores.push("Stock inválido");

  if (errores.length > 0) {
    return { ok: false, errores };
  }
  return { ok: true, producto: { nombre: datos.nombre.trim(), precio, stock } };
}

Fíjate en dos decisiones. Primero, se recogen todos los errores y no solo el primero: en la UD4 querrás mostrarlos todos al usuario a la vez. Segundo, la función devuelve un resultado que describe qué pasó, en lugar de lanzar: para una validación esperable, un error no es excepcional.

Validar en el borde

Comprobar los datos en el punto donde entran al programa —el formulario, el fichero, la respuesta del servidor— y no dentro de cada función que los usa. Después de ese punto, el resto del código puede confiar.

Tarea 14 · Blinda tu catálogo

Añade validación a crearProducto con al menos cinco reglas.
Haz que devuelva la lista completa de errores.
Protege valorAlmacen frente a productos sin precio o sin stock.
Envuelve una lectura de JSON en try/catch y da un mensaje útil.
Escribe cinco entradas inválidas y comprueba que ninguna pasa.

Objetivo mínimoValidación con lista de errores y un try/catch con mensaje claro.

Si lo tienesDistingue con throw los fallos de programación de los de datos.

RetoEscribe una función que valide un objeto contra un esquema de reglas declarado como dato.

Checkpoint · fin de la sesión 14

Lanzas errores con un mensaje que dice qué se esperaba.
Capturas solo lo que sabes tratar.
Validas donde entran los datos, no en cada función.
Devuelves todos los errores de validación, no solo el primero.

Antes de cerrar · 2 minutos, sin mirar

¿Qué hace finally?
¿Por qué es peligroso un catch vacío?
¿Qué significa validar en el borde?

Ver respuestas

1 · Se ejecuta haya error o no, para lo que hay que hacer en cualquier caso.

2 · Porque oculta el fallo y el programa continúa con datos que no tiene.

3 · Comprobar los datos en el punto donde entran, para que el resto del código pueda confiar en ellos.