Tipos de errores en JavaScript: Syntax, Type y Reference

Los errores son objetos con un tipo

Cuando JavaScript lanza un error, no te devuelve un simple string: te devuelve un objeto. Ese objeto tiene un tipo (su constructor) y varias propiedades estándar: name, message y stack.

err.name es una etiqueta corta como "TypeError". err.message es la descripción legible para humanos. Con err instanceof TypeError sabes exactamente de qué clase se trata. Conocer el tipo importa: te dice si el problema es una errata, un valor incorrecto o código que ni siquiera se pudo parsear.

Existen siete tipos de errores integrados en JavaScript. Tres los vas a ver todo el tiempo; los otros cuatro aparecerán de vez en cuando.

SyntaxError en JavaScript: cuando el código no parsea

Un SyntaxError significa que JavaScript ni siquiera pudo leer tu código. En realidad no es un error en tiempo de ejecución: el motor falla durante el parseo, antes de que se ejecute una sola línea. No puedes capturarlo con try/catch dentro del mismo archivo, porque el archivo entero queda descartado.

function greet(name {
    return "hi, " + name;
}
// SyntaxError: Unexpected token '{'

Un corchete que falta, una coma de más, un return fuera de una función… cualquier cosa que rompa la gramática del lenguaje lanza este error. La solución siempre pasa por corregir el código fuente. El único caso en el que sí puedes atrapar un SyntaxError es cuando el parseo ocurre en tiempo de ejecución, como sucede con JSON.parse:

JSON.parse recibe una cadena en tiempo de ejecución, así que sus errores de sintaxis sí se pueden atrapar con try/catch. Los errores en tus propios archivos fuente, no.

ReferenceError: ese nombre no existe

Un ReferenceError salta cuando haces referencia a una variable que no se ha declarado en ningún ámbito visible desde el código actual.

El noventa por ciento de las veces se trata de un typo (totl en lugar de total). El otro diez por ciento es cosa del scope: estás intentando usar algo declarado en otra función u otro módulo.

Hay una causa más sutil: la temporal dead zone (zona muerta temporal). Las declaraciones con let y const existen desde el inicio de su bloque, pero no puedes acceder a ellas antes de la línea que las declara:

x sí es un binding real cuando se ejecuta console.log(x), lo que pasa es que todavía no se ha inicializado. De ahí viene el error de referencia. La solución es mover el acceso a una línea posterior a la declaración.

TypeError: el valor tenía la forma equivocada

Un TypeError significa que el valor existe, pero no es del tipo que la operación espera. Llamar a algo que no es una función, leer una propiedad de null o undefined, asignar a una const... todos son TypeError.

"Cannot read properties of null (reading 'name')" es, probablemente, el mensaje de error más común de todo JavaScript. La solución pasa por asegurarte de que el valor existe, o bien por proteger el acceso con optional chaining: user?.name.

Otras variantes del TypeError:

Llamar a un número como si fuera función, reasignar una const o invocar un método que no existe: el valor no era del tipo correcto para lo que le pediste.

RangeError: el número está fuera de rango

El RangeError se dispara cuando un número es técnicamente válido, pero queda fuera del rango permitido para una operación concreta.

Una fuente clásica es la recursión infinita, que revienta la pila de llamadas:

"Maximum call stack size exceeded" casi siempre significa que una función se está llamando a sí misma sin un caso base, o que dos funciones se están llamando entre sí en bucle.

URIError y EvalError: los raros

URIError aparece cuando las funciones de manejo de URI (encodeURI, decodeURIComponent y compañía) reciben una entrada mal formada:

EvalError es una reliquia. Los motores modernos de JavaScript ya no lo lanzan para nada; solo sigue existiendo como constructor por compatibilidad con código antiguo. Puedes crearlo a mano, pero no te lo vas a topar en el código real.

La cadena de herencia

Todos estos tipos de errores heredan de un Error base. Esto significa que err instanceof Error devuelve true para cualquiera de ellos, lo cual viene de perlas en un catch genérico:

Un bloque catch atrapa todo — incluso valores que no son errores si alguien hace throw "oops". Esa última rama importa. Siempre acota con instanceof antes de tratar el valor capturado como un objeto de error.

Cómo lanzar errores a propósito

Tú mismo puedes lanzar cualquiera de los tipos integrados cuando tu código detecte un problema. Elige el tipo que mejor describa el fallo:

Elegir el tipo adecuado para cada fallo no es solo una cuestión estética: permite que quien consume tu código escriba bloques catch más precisos, en lugar de andar parseando mensajes de error con cadenas.

Crear errores personalizados en JavaScript

Cuando ninguno de los tipos nativos encaja bien con tu caso, lo mejor es extender Error:

Dos cosas importantes: llama a super(message) para que la clase base Error se inicialice bien, y asigna this.name para que los logs muestren la etiqueta correcta. Los campos personalizados como field permiten que quien llame reaccione a fallos concretos sin tener que parsear cadenas de texto.

Siguiente paso: la consola y las DevTools

Conocer los tipos de errores en JavaScript es solo la mitad del camino. La otra mitad es saber leer un stack trace y husmear el estado mientras el programa se ejecuta. Las devtools del navegador (y el debugger de Node) convierten ese "lanzó un error y no tengo idea de por qué" en unos segundos de inspección. Eso lo vemos a continuación.