Errores personalizados: ponle nombre a tus fallas

En el módulo 10 te prometí que aquí aprenderías a crear errores propios. Momento de cumplir. Un new Error("falló") genérico no distingue "el usuario escribió mal" de "el servidor se cayó" —y esa diferencia decide qué hace tu app. Hoy fabricas tus propios tipos de error, con nombre y datos, usando las clases del módulo 11.

Etiquetas para cada tipo de falla

extends Error: tu error, con tu apellido

Un error personalizado es una clase que hereda de Error (módulo 11). Llamas a super(message) para heredar toda la maquinaria (mensaje, stack) y le pones tu propio name:

Fíjate en lo importante: tu error sigue siendo un Error (instanceof Error da true), así que hereda todo —stack, comportamiento en la consola—; solo le añadiste identidad. El super(mensaje) es obligatorio: es lo que conecta tu clase con la maquinaria nativa (si lo olvidas, pierdes el mensaje y el stack).

instanceof en el catch: reaccionar distinto a cada falla

Aquí brilla la idea. Un solo catch recibe TODOS los errores; con instanceof decides qué hacer según el tipo —el triaje en acción:

Este es el patrón profesional. En vez de un catch que lee el mensaje con if (error.message.includes("saldo")) —frágil, se rompe si cambias una palabra—, preguntas por el TIPO. Y nota la joya de la última rama: si el error no es de los tuyos, lo re-lanzas (throw error) para que lo maneje quien sepa. Atrapar solo lo que sabes manejar y dejar pasar el resto es madurez de ingeniero.

Errores con datos: más que un mensaje

Como es una clase tuya, puedes adjuntarle los datos que necesites: un código, el campo que falló, el valor recibido. El catch los recibe listos para usar:

Con error.campo sabes EXACTAMENTE qué input marcar en rojo, sin parsear texto. Así es como una librería seria de validación (lo verás con Zod en el supercurso de TypeScript) te entrega errores: objetos ricos, no strings. Un error bien diseñado no solo dice que algo falló —dice qué, dónde y con qué valor.

Mini-reto

Diseña una jerarquía: 1) crea class BolsilloError extends Error como base (con su name); 2) crea FondosInsuficientesError extends BolsilloError y CategoriaInvalidaError extends BolsilloError; 3) lanza uno de los hijos y comprueba en el catch que instanceof BolsilloError da true (atrapa toda la familia con una sola rama) pero también puedes distinguir el hijo exacto. Esa herencia de errores es como organizan sus fallas las apps grandes.

Qué sigue

Ya sabes crear y distinguir errores. Pero saber la MECÁNICA no es saber la ESTRATEGIA: ¿dónde conviene atrapar? ¿qué es un error esperado y qué es un bug? ¿cuándo re-lanzar? La próxima lección es la que separa el código que falla con dignidad del que falla con caos.