JavaScript
Introduce los errores de sintaxis, ejecución y lógica, el objeto Error, las trazas y la diferencia entre fallos esperados, operativos y de programación.
Un error indica que el programa no puede continuar una operación de la manera esperada.
function divide(dividend, divisor) {
if (divisor === 0) {
throw new Error("Cannot divide by zero");
}
return dividend / divisor;
}El código no puede interpretarse correctamente.
const user = {
name: "Nicolás",
// Falta cerrar el objeto.El motor normalmente detecta el problema antes de ejecutar ese archivo.
La sintaxis es válida, pero una operación falla al ejecutarse.
const user = null;
user.name;
// TypeErrorEl programa se ejecuta sin lanzar una excepción, pero produce un resultado incorrecto.
function calculateDiscount(price, percentage) {
return price - percentage;
}Para un precio de 100 y un descuento de 20%, la función devuelve 80 por casualidad. Para 200, devuelve 180, aunque debería devolver 160.
Los errores lógicos se descubren mediante comprensión del problema, pruebas y debugging; no siempre generan un objeto Error.
En conversaciones técnicas suelen utilizarse como sinónimos, pero conviene distinguir la idea:
throw o por el propio entorno.throw new Error("Operation failed");JavaScript busca un bloque capaz de manejar esa excepción. Si no encuentra uno, llega hasta el entorno superior y normalmente se reporta como error no capturado.
const error = new Error("Product not found");Propiedades habituales:
error.name;
error.message;
error.cause;
error.stack;name describe la clase general del error y message explica el caso concreto.
stack suele mostrar la cadena de llamadas activa, pero su formato depende del runtime y no debe tratarse como un contrato portable para lógica de negocio.
function readProduct() {
return loadProduct();
}
function loadProduct() {
throw new Error("Database unavailable");
}
readProduct();La traza puede mostrar algo parecido a:
Error: Database unavailable
at loadProduct
at readProduct
at mainPermite responder:
Un usuario escribe una contraseña incorrecta o busca un producto inexistente.
Eso puede representarse como un resultado normal:
function findProduct(products, productId) {
return (
products.find(
(product) => product.id === productId,
) ?? null
);
}function createPercentage(value) {
if (!Number.isFinite(value)) {
throw new TypeError(
"Percentage must be a finite number",
);
}
if (value < 0 || value > 100) {
throw new RangeError(
"Percentage must be between 0 and 100",
);
}
return value;
}La entrada viola las condiciones necesarias para crear un porcentaje válido.
No existe una regla universal de “todo se retorna” o “todo se lanza”. El contrato debe expresar si una ausencia es esperada o si la operación quedó en un estado inválido.
Son fallos causados por una suposición incorrecta dentro del código.
function printUser(user) {
return user.name.toUpperCase();
}
printUser(undefined);Capturarlos silenciosamente puede esconder un bug.
try {
printUser(undefined);
} catch {
// No hacer nada.
}El programa parece continuar, pero la causa permanece.
Ocurren aunque el código esté bien diseñado:
Suelen requerir una estrategia:
const error = new Error("Failed");
typeof error;
error instanceof Error;Puedes agregar información propia, aunque para contratos importantes suele ser mejor definir una clase de error.
error.code = "PRODUCT_NOT_FOUND";
error.productId = "product-1";Menos confiable:
if (error.message === "Product not found") {
// ...
}El mensaje puede cambiar por redacción, traducción o contexto.
Más estable:
if (error.code === "PRODUCT_NOT_FOUND") {
// ...
}O mediante una clase:
if (error instanceof ProductNotFoundError) {
// ...
}El mensaje está pensado principalmente para diagnóstico humano. Un code, tipo o propiedad explícita sirve mejor para decisiones del programa.
Number("hello"); // NaNNo se lanza una excepción. La operación produce el valor especial NaN.
JSON.parse("invalid");
// Lanza SyntaxError.Cada API define su contrato. Debes saber si:
null o undefined.Un error síncrono se propaga por el Call Stack actual.
try {
throw new Error("Failed");
} catch (error) {
console.log(error.message);
}Un callback ejecutado después pertenece a otra llamada.
try {
setTimeout(() => {
throw new Error("Failed later");
}, 0);
} catch {
// No lo captura.
}El try ya terminó cuando se ejecuta el callback.
Las promesas representan sus fallos mediante rechazo. Se estudiarán con profundidad en el bloque de asincronía.
Un error síncrono que llega al entorno sin ser capturado suele reportarse como uncaught exception.
Una promesa rechazada sin un manejador puede reportarse como unhandled rejection.
El comportamiento final depende del navegador, Node.js u otro host. En ambos casos indican que ninguna capa asumió la responsabilidad del fallo.
Menos claro:
try {
return users.find(
(user) => user.id === userId,
).name;
} catch {
return "Unknown";
}Más explícito:
const user = users.find(
(candidate) => candidate.id === userId,
);
return user?.name ?? "Unknown";Las excepciones son apropiadas cuando la operación no puede cumplir su contrato, no para reemplazar decisiones normales que el código puede expresar directamente.
function readPort(environment) {
const rawPort = environment.PORT;
if (rawPort === undefined) {
return 3000;
}
const port = Number(rawPort);
if (!Number.isInteger(port)) {
throw new TypeError(
"PORT must be an integer",
);
}
if (port < 1 || port > 65535) {
throw new RangeError(
"PORT must be between 1 and 65535",
);
}
return port;
}La ausencia tiene un valor predeterminado. Un valor presente pero inválido produce un error porque continuar con él haría que la configuración fuera engañosa.
stack tiene el mismo formato en todos los runtimes.null para cualquier fallo sin documentar qué significa.Error es un objeto con nombre, mensaje y contexto de diagnóstico.throw interrumpe el flujo normal.¿Cuál de estas funciones debería lanzar un error y cuál podría devolver null?
function divide(a, b) {}
function findUser(users, userId) {}divide debería rechazar un divisor cero si su contrato no define otro resultado válido. findUser puede devolver null cuando la ausencia de un usuario es un resultado esperado. La decisión final depende del contrato documentado.
Tipos de errores explica las clases nativas y qué clase comunica mejor cada categoría de fallo.