Todo el código que has escrito en este módulo asume que los datos son correctos: que horasEstimadas es un número, que prioridad vale 'alta', 'media' o 'baja', que la fecha límite tiene formato ISO. En cuanto Nómada Tareas tenga un formulario, esa suposición se romperá el primer día: Iván escribirá "dos" donde iban las horas, alguien dejará el título en blanco y otra persona pondrá una fecha del año pasado. Sin protección, el programa hace una de dos cosas, ambas malas: produce un NaN silencioso que contamina todos los cálculos posteriores, o se detiene en seco con un mensaje que Marta no entiende. En esta lección aprenderás a detectar esas situaciones, a interrumpir la ejecución con un error propio y un mensaje útil, y a capturarlo para decidir qué hacer sin que la aplicación entera se venga abajo.

1. Errores de sintaxis y excepciones: no son lo mismo
2. Qué ocurre cuando nadie captura una excepción
3. try y catch
4. finally y el flujo completo
5. El objeto Error: name, message y stack
6. Los tipos de error incorporados
7. throw: lanzar tus propios errores
8. Por qué se lanza un Error y no una cadena
9. Errores personalizados: la receta breve
10. Validar entradas y fallar pronto
11. Qué NO capturar: silenciar errores es un antipatrón
12. Los errores asíncronos son otra historia
13. Caso práctico: aceptar tareas nuevas del formulario
14. Errores Comunes y Consejos
15. Ejercicios
16. Conclusión

Cuando en la lección 01-03 aprendiste a leer un error de la consola, no distinguimos entre dos cosas muy distintas. Ahora sí hace falta.

Un error de sintaxis es un fallo del programador, se detecta antes de ejecutar y no tiene sentido "manejarlo": se corrige. Una excepción es una situación anómala que ocurre mientras el programa funciona, casi siempre porque los datos no eran los que esperabas. Esa es la que se maneja.

Cuando se lanza una excepción y nadie la recoge, la ejecución se detiene ahí mismo. Nada de lo que venía después se ejecuta.

Salida:

La palabra clave es Uncaught: significa "nadie ha capturado esto". En Node.js el proceso termina con código de error; en el navegador se detiene el bloque de código actual, aunque el resto de la página sigue viva y los botones que ya tenían escuchadores seguirán respondiendo.

Ese comportamiento —detenerse— es deliberado y correcto. Si el programa siguiera adelante con datos rotos, produciría resultados falsos que nadie detectaría. Es preferible parar en el punto exacto del fallo.

Lo que aporta try/catch no es evitar la parada: es decidir qué se para. Que una tarea del formulario esté mal no debería impedir procesar las otras cuatro.

La estructura básica tiene dos bloques:

Con un ejemplo del proyecto: los datos de una tarea llegan como texto JSON desde el almacenamiento del navegador y pueden estar corruptos.

Salida:

Lo esencial:

• El bloque try se ejecuta normalmente hasta que algo falla. Si nada falla, catch se salta por completo.
• Cuando algo falla, la ejecución salta al catch inmediatamente. El resto del try no se ejecuta: en el ejemplo, el console.log('Tareas recuperadas...') nunca llega a correr.
• error es un parámetro que recibe el objeto que describe el fallo. Puedes llamarlo como quieras; error, err y e son los nombres habituales.
• El programa continúa después del catch. Esa es toda la magia.

Si no necesitas el objeto de error, JavaScript moderno permite omitir el paréntesis:

Mantén el try lo más pequeño posible. Envolver cincuenta líneas en un solo try significa que cualquiera de ellas puede haber fallado y el catch no sabe cuál. Envuelve solo la operación que de verdad puede fallar.

finally es un tercer bloque opcional que se ejecuta siempre: haya fallado algo o no, se haya capturado o no.

Salida:

finally sirve para las tareas de limpieza que deben ocurrir sí o sí: cerrar una conexión, ocultar un indicador de carga, desbloquear un botón. En Nómada Tareas su caso típico será este, ya en el Módulo 6:

Sin finally tendrías que repetir esa línea en el try y en el catch. Con él se escribe una vez y se ejecuta seguro.

Detalle importante: finally se ejecuta incluso si el catch vuelve a lanzar el error. Y también se ejecuta si no hay catch en absoluto: try/finally sin catch es una combinación legal y útil cuando quieres limpiar pero dejar que el error suba.

Lo que recibe el catch es un objeto con tres propiedades fundamentales:

name y message son los que usarás a diario: name para decidir qué hacer y message para explicar qué ha pasado.

stack es la herramienta de diagnóstico. Contiene el recorrido que siguió la ejecución hasta el punto del fallo, con nombres de fichero y números de línea. Se lee de arriba abajo: la primera línea es donde se produjo el error y las siguientes, quién lo provocó. En el Módulo 3, cuando tengas funciones llamando a funciones, la pila se volverá realmente informativa; hoy tiene una o dos líneas.

Registra el error completo, no solo el mensaje. console.error(error) en la consola del navegador muestra el objeto entero con su traza plegable; console.error(error.message) tira esa información a la basura y te deja sin saber dónde ocurrió.

JavaScript define varios tipos de error. Todos comparten name, message y stack, y se diferencian en la clase de problema que representan.

Los tres primeros son los que verás el 95 % del tiempo. Compruébalos:

Conocer el tipo permite reaccionar de forma distinta a cada uno:

Existe una forma más idiomática de hacer esa comprobación —error instanceof SyntaxError—, pero instanceof pertenece al mundo de los prototipos y las clases, que se estudia en el Módulo 5. Comparar error.name con un texto funciona perfectamente y es lo que usaremos por ahora.

Hasta aquí has capturado errores que lanzaba JavaScript. La otra mitad del mecanismo es lanzarlos tú, con throw, cuando detectas que una regla de negocio no se cumple.

Qué hace throw, exactamente:

1. Detiene la ejecución en ese punto. Como el break de la lección anterior, pero mucho más radical: no salta a la siguiente iteración, abandona todo el bloque try.
2. Busca el catch más cercano que envuelva esa línea.
3. Si no hay ninguno, el error queda Uncaught y el programa se detiene.

new Error(...) crea el objeto de error. El texto que le pasas se convierte en su message. Puedes usar Error genérico o el tipo que mejor describa el problema: RangeError para valores fuera de rango, TypeError para tipos incorrectos.

Cómo escribir un buen mensaje de error. El mensaje lo leerá alguien que intenta arreglar algo, así que debe contener tres cosas:

Todo junto:

Ese mensaje se explica solo, sin abrir el código.

throw acepta cualquier valor. Esto es legal:

Y es una mala idea por tres motivos concretos:

1. Pierdes la traza. Una cadena no tiene stack, así que en el catch no hay forma de saber en qué línea se originó el problema. Con proyectos de más de un fichero, esto convierte la depuración en adivinanza.

2. Pierdes el tipo. error.name es undefined, así que no puedes reaccionar de forma distinta según la clase de problema.

3. Rompes el código que captura. Un catch bien escrito hace error.message. Si le llega una cadena, error.message vale undefined y el mensaje se pierde. Peor: si alguien lanza null, error.message provoca a su vez un TypeError dentro del catch.

Compáralo:

Norma sin excepciones: lanza siempre un objeto Error o uno de sus tipos derivados.

Cuando quieras distinguir tus errores de negocio de los del lenguaje, puedes crear un tipo propio. La receta es esta, y de momento basta con copiarla:

Se usa igual que cualquier otro error, con la ventaja de llevar información adicional:

La ventaja práctica es doble: puedes filtrar en el catch los errores que sabes tratar y dejar pasar los demás, y puedes adjuntar datos —el campo, el valor recibido, el id de la tarea— que el formulario usará para marcar en rojo el recuadro correcto.

Qué significan exactamente class, extends, constructor, super y this se explica en Clases y POO. Aquí es solo una plantilla que puedes reutilizar cambiando el nombre.

El principio se llama fail fast: comprobar los datos en el momento en que entran al sistema y rechazarlos ahí mismo, en lugar de dejarlos avanzar y descubrir el problema tres capas más adentro.

La diferencia se ve mejor con un ejemplo. Sin validación:

El NaN no provoca ningún error: se propaga en silencio por todos los cálculos y aparece al final, en un informe, sin ninguna pista de cuál fue la tarea culpable. Este es exactamente el escenario contra el que te previno la lección 01-07.

Con validación en la entrada:

El fallo se detecta en el punto exacto donde entró el dato malo, el mensaje nombra el campo y el valor recibido, y ningún cálculo posterior llega a contaminarse.

Fíjate en que se usa Number.isNaN(horas) y no isNaN(horas): la distinción de la lección 01-07 sigue siendo la correcta, porque isNaN convierte antes de comprobar y da falsos positivos.

El orden de las validaciones importa. Primero el tipo, después el rango. Comprobar horas > 40 cuando horas es NaN da false, y la validación pasaría sin detectar nada: todas las comparaciones con NaN son falsas.

try/catch es una herramienta poderosa, y como toda herramienta poderosa se usa mal con facilidad. Estos son los tres abusos que hay que evitar.

1. El catch vacío. El peor de todos.

Esto no maneja el error: lo oculta. El programa continúa con un estado incorrecto, sin dejar ni rastro en la consola, y el fallo emergerá más tarde en otro sitio completamente distinto. Depurar eso puede costar horas. Si de verdad un error concreto es esperable e ignorable, escríbelo explícitamente:

2. Capturar errores de programación. Un TypeError por escribir mal el nombre de una variable es un bug, no una situación excepcional. Envolverlo en un try/catch no lo arregla: lo esconde. Los bugs se corrigen; solo se capturan las situaciones que el programa no controla.

3. El try gigante. Envolver un bloque de cien líneas hace que el catch no pueda saber qué falló ni reaccionar de forma sensata. Envuelve la operación arriesgada, no el programa entero.

Y un patrón que sí es correcto: capturar, enriquecer y volver a lanzar.

Es lo que harás en capas intermedias: registrar información útil sin decidir tú qué hacer con el problema.

Una advertencia importante para que no te pille por sorpresa más adelante: try/catch solo captura errores del código que se ejecuta ahora mismo, dentro del bloque try. Si dentro del try inicias una operación que terminará más tarde —una petición a un servidor, un temporizador—, el try habrá terminado hace rato cuando esa operación falle, y el catch no se enterará.

El error se lanza un segundo después, cuando el try/catch ya no existe, y queda como Uncaught.

El manejo de errores en código asíncrono tiene sus propias herramientas: .catch() en las promesas y try/catch combinado con await, que sí funciona. Todo eso se estudia en Promesas y Async/Await. Por ahora quédate con la regla: try/catch protege lo síncrono.

Cerramos el módulo juntando todo lo aprendido. Marta ha recogido cinco solicitudes de tarea en un formulario y hay que procesarlas: aceptar las válidas, rechazar las que incumplan las reglas y —esto es lo importante— que una solicitud mala no impida procesar las siguientes.

Los datos llegan como texto, tal y como salen de un formulario HTML.

Salida:

Repasa las decisiones de diseño, porque son las que aplicarás en todo el proyecto:

• El try está dentro del bucle, no fuera. Esta es la clave de todo el ejemplo. Con el try envolviendo el bucle entero, la primera solicitud inválida habría abortado el proceso y las tres siguientes no se habrían revisado nunca. Poniéndolo dentro, cada solicitud se procesa de forma independiente y un dato malo solo afecta a su propia fila.
• throw funciona como una salida temprana perfecta. Es la cláusula de guarda de la lección 02-01, esta vez con una salida real: en cuanto una regla falla, el resto de validaciones de esa solicitud se descartan. No hay anidamiento, no hay variable error que arrastrar, no hay else.
• Cada throw elige su tipo de error. TypeError para un tipo equivocado, RangeError para valores fuera de rango, Error genérico para el resto de reglas de negocio. Con eso, el catch podría reaccionar distinto a cada familia.
• El orden de las validaciones es deliberado. El tipo antes que el rango, siempre. Y las comprobaciones baratas antes que las caras, como aprendiste en la lección 02-04.
• Aparecen las cuatro estructuras del módulo. El for externo que recorre las solicitudes, el for interno con break que busca al responsable en el equipo, los if de cada validación y el try/catch que lo envuelve todo. Ese es el módulo completo funcionando junto.

Y ahora fíjate en algo incómodo: el bloque de validación tiene cuarenta líneas y solo sirve para esto. Si mañana hay que validar una tarea editada en lugar de una nueva, hay que copiarlo entero.

El catch vacío. Ya lo has visto, pero merece repetirse: es el peor error de esta lección. Un catch que no registra nada convierte un fallo localizado en un misterio.

Lanzar cadenas en lugar de objetos Error. Pierdes name y stack, y rompes cualquier catch que espere un error de verdad.

Poner el try fuera del bucle cuando debía ir dentro. Una entrada mala aborta el proceso completo. Pregúntate siempre: ¿un fallo aquí debe detenerlo todo o solo esta iteración?

Usar try/catch para lo que resuelve un if. Comprobar si un valor es negativo no requiere excepciones: requiere una condición. Las excepciones son para lo excepcional; si el "error" ocurre en el flujo normal, es un caso, no una excepción.

Esperar que try/catch capture errores asíncronos. No lo hace. setTimeout, fetch y las promesas necesitan otro tratamiento, que verás en el Módulo 5.

Comprobar el rango antes que el tipo. Con NaN todas las comparaciones dan false, así que un valor no numérico pasa cualquier validación de rango sin detectarse.

Registrar solo error.message. Pierdes la traza. Usa console.error(error) cuando estés depurando.

Consejo: escribe el mensaje pensando en quien lo va a leer a las tres de la madrugada. Qué falló, qué valor lo causó y qué se esperaba. Los tres ingredientes, siempre.

Consejo: incluye el identificador de la regla en el mensaje. R3: al principio del texto conecta el error con la especificación del proyecto y ahorra mucho tiempo.

Consejo: prueba tus validaciones con datos malos a propósito. Escribe deliberadamente 'dos', -5, '' y null y comprueba que cada uno produce el mensaje que esperabas. Es el germen de las pruebas unitarias del Módulo 8.

Ejercicio 1 — Lectura robusta del tablero guardado

Escribe un bloque try/catch/finally que intente leer con JSON.parse el contenido de la variable guardado. Si el texto es válido, muestra un mensaje de éxito; si está corrupto, avisa de que se empieza con un tablero vacío. En finally, imprime siempre "Tablero listo". Pruébalo con '[1,2,3]' y con '{ roto', y explica por qué usar if en lugar de try/catch no sería viable aquí.

Ejercicio 2 — Validador de transiciones que lanza errores

Reescribe la validación de cambio de estado de la lección 02-01 usando throw en lugar de las variables permitido y motivo. Debe lanzar un Error con mensaje descriptivo cuando el estado nuevo no exista, cuando sea igual al actual o cuando la transición no esté permitida por R6. Envuélvelo en un try/catch y pruébalo con pendiente → hecha y con en-curso → hecha.

Ejercicio 3 — Errores personalizados con el campo culpable

Usando la receta de la sección 9, crea ErrorDeValidacion con las propiedades campo y valorRecibido. Valida una tarea con titulo = '', horas = '35' y prioridad = 'baja', y haz que el catch distinga entre tus errores de validación —mostrando el campo culpable— y cualquier otro error inesperado.

Ejercicio 1

Con '[1,2,3]':

Con '{ roto':

Por qué no sirve un if: para saber si un texto es JSON válido habría que analizarlo carácter a carácter, es decir, reimplementar JSON.parse entero. No existe ninguna comprobación previa razonable. Este es el caso arquetípico de try/catch: la única forma de saber si la operación funciona es intentarla. Cuando puedas comprobarlo antes con una condición, usa la condición; cuando no, captura.

El finally garantiza que la aplicación continúa por ambos caminos con el mismo mensaje, sin duplicarlo en los dos bloques.

Ejercicio 2

Con pendiente → hecha:

Con en-curso → hecha:

Compara esta versión con la de la lección 02-01: allí hacían falta las variables permitido y motivo, y cada rama tenía que asignar las dos. Aquí cada guarda o lanza o deja pasar, y el camino feliz —el console.log final— está al mismo nivel de indentación que todo lo demás.

Fíjate también en que las cuatro transiciones válidas se han agrupado en una sola expresión booleana con paréntesis, aplicando la norma de la lección 02-01: cuando se mezclan && y ||, los paréntesis van aunque la precedencia ya sea correcta.

Ejercicio 3

Tres cosas que hacen valioso este patrón:

1. error.campo permite que la interfaz reaccione. En el Módulo 6, ese dato marcará en rojo exactamente el recuadro del formulario que hay que corregir, en lugar de mostrar un aviso genérico.
2. JSON.stringify(error.valorRecibido) muestra el valor entre comillas, lo que distingue el texto vacío "" de un espacio " " o de null. Un console.log normal imprimiría los tres de forma indistinguible.
3. La rama else no silencia nada. Los errores que no son de validación —un TypeError por un bug tuyo— se registran completos, con su traza. Filtrar lo que sabes tratar y dejar visible lo demás es la diferencia entre manejar errores y esconderlos.

Cambia titulo por 'Renovar el torno' y verás cómo la validación avanza hasta el final e imprime ✓ Tarea válida., porque 35 h está dentro de rango y 'baja' es una prioridad correcta.

Con esta lección cierras el Módulo 2. Ya distingues un error de sintaxis —un fallo del código, que se corrige— de una excepción —una situación anómala en ejecución, que se maneja—. Sabes que una excepción sin capturar detiene el programa, y que try/catch no evita la parada sino que te deja decidir qué se para: en el ejemplo del formulario, una solicitud inválida ya no impide procesar las otras cuatro. Conoces finally para la limpieza que debe ocurrir pase lo que pase, el objeto Error con su name, su message y su stack, y los tipos incorporados que te permiten reaccionar de forma distinta a cada clase de problema.

Sabes lanzar tus propios errores con throw, siempre con un objeto Error y nunca con una cadena, y escribir mensajes que digan qué falló, qué valor lo causó y qué se esperaba. Tienes la receta de los errores personalizados para adjuntar el campo culpable. Y —tan importante como lo anterior— sabes lo que no hay que capturar: un catch vacío no maneja un error, lo esconde; los bugs se corrigen en lugar de envolverse; y los errores asíncronos necesitan las herramientas del Módulo 5.

Mira atrás y comprueba lo que has ganado en estas cinco lecciones. Tu código decide con if/else if y con switch, repite con for, while y do...while, recorre el backlog completo acumulando, contando, buscando extremos y cruzando listas con bucles anidados, corta en el momento justo con break y continue, y se defiende de los datos malos con validaciones que fallan pronto y con mensajes útiles. Eso ya es un programa de verdad.

Y también has ido acumulando una queja, lección tras lección. La cadena que convierte prioridad en un peso la has escrito cuatro veces. La validación de transiciones aparece en dos lecciones casi idéntica. El bloque de cuarenta líneas que valida una tarea nueva no puede reutilizarse para validar una tarea editada sin copiarlo entero. Y cuando quisiste salir de dos bucles a la vez, la solución más limpia resultó ser una que todavía no podías escribir. Todo apunta al mismo sitio: necesitas poder dar un nombre a un trozo de lógica, guardarlo y usarlo tantas veces como quieras, con datos distintos cada vez. Eso es una función, y es exactamente lo que empieza en el Módulo 3: Funciones, con Definición y Llamada de Funciones. A partir de ahí, validarTarea(), calcularUrgencia() y puedeCambiarEstado() dejarán de ser bloques copiados para convertirse en piezas con nombre propio que podrás combinar, probar y reutilizar en todo Nómada Tareas.