Pregunta 1Del texto que aparece cuando la ejecución se detiene, ¿cuál indica dónde se detuvo?
Cómo leer errores y logs — dónde mirar y qué contar para poder arreglarlo
Este artículo forma parte del curso Fundamentos de informática, que construye desde cero los conocimientos prácticos de informática que necesitas como mínimo para programar y hacer vibe coding.
Dónde mirar se divide en tres: el mensaje de error, el stack trace y el log. Con diagramas veremos dónde mirar y qué contarle a quien te responde para que el problema se pueda arreglar.
Este artículo trata cómo leer los mensajes de error y los logs.
El texto que aparece cuando la ejecución se detiene y los registros que quedan mientras el programa funciona son dos cosas distintas.
A partir de un único suceso, «apareció un error», los lugares donde mirar se dividen en tres.
Los dos de arriba son texto que aparece cuando la ejecución se detiene; el de abajo es un registro que queda mientras el programa funciona.
Cuando la ejecución se detiene, aparecen un mensaje de error y un stack trace
Cuando ocurre un error (la ejecución se detiene porque ya no puede seguir con las instrucciones), el entorno de ejecución escribe en texto qué ha pasado.
Ese texto se divide en dos partes con papeles distintos.
Si ejecutas app.js de my-app, una app de reservas, con node app.js, al detenerse aparece este texto.
/Users/you/my-app/app.js:5
return items.price * items.count;
^
TypeError: Cannot read properties of undefined (reading 'price')
at keisan (/Users/you/my-app/app.js:5:16)
at goukei (/Users/you/my-app/app.js:9:10)
at Object.<anonymous> (/Users/you/my-app/app.js:13:13)
at Module._compile (node:internal/modules/cjs/loader:1356:14)
La línea que empieza por TypeError es el mensaje de error, y las cuatro líneas de debajo que empiezan por at son el stack trace.
Esa única línea de mensaje de error también se divide en tres: el tipo, la descripción y el objetivo.
Todo el texto que aparece en pantalla
Mensaje de error — qué ha pasado
TypeError
- Tipo de error — el nombre de la categoría del problema
- Dónde mirar primero depende del nombre
Cannot read properties of undefined
- Descripción — qué no se pudo hacer
- Hay un valor que quedó en undefined
(reading 'price')
- Objetivo — qué valor o nombre falló
- Intentó leer price y falló
Stack trace — dónde se detuvo
- Una lista de líneas que empiezan por at
- Líneas de app.js que escribiste tú
- Líneas de dentro de las bibliotecas y del entorno de ejecución
La parte más interna, el tipo de error (error type; el nombre que el entorno de ejecución da a la categoría del problema), cambia dónde miras primero según cuál sea el nombre.
El texto indica qué ha pasado y dónde
El texto rojo de la pantalla está formado por dos cosas: un mensaje de error que indica brevemente qué ha pasado y un stack trace que enumera dónde se detuvo.
El mensaje de error se lee en tres partes (tipo, descripción y objetivo) y, en cuanto sabes el nombre del tipo, puedes deducir dónde abrir después.
El stack trace es la lista de los lugares por los que pasó antes de detenerse
Un programa está dividido en bloques de procesamiento, y un bloque va llamando a otro a medida que avanza.
Cada línea de la lista es un bloque de procesamiento que seguía en curso cuando se detuvo.
Cuanto más arriba está una línea, más interna es; cuanto más abajo, más externa.
| La línea de la lista | Qué se estaba ejecutando | Qué hizo ahí | Dónde mirar después |
|---|---|---|---|
| at keisan | keisan | Intentó leer items.price | Es la línea donde se detuvo |
| at goukei | goukei | Llamó a keisan | El data.cart que pasó |
| at Object.<anonymous> | La línea más externa | Llamó a goukei | El valor que pasó aquí es el origen |
La línea de keisan es donde se detuvo, pero allí solo hay una expresión que usa el valor recibido.
Si sigues el valor que se le pasó, llegas a la línea 13, la más externa.
Lo que se pasó ahí no contiene price, así que se detuvo cuando keisan intentó leerlo.
En la lista también aparecen nombres de archivo distintos del app.js que escribiste tú.
Lo primero que abres es la línea de un archivo escrito por ti.
El orden y las palabras cambian según el entorno de ejecución.
Python escribe File en lugar de at, y a la lista entera la llama traceback (traceback; otro nombre para el stack trace).
Las líneas de la lista son llamadas de dentro hacia fuera
El stack trace es la lista de dónde se detuvo la ejecución y de los lugares por los que pasó para llegar hasta ahí.
Cada línea es un bloque de procesamiento y, cuanto más arriba está, más interna es; la forma de escribirlo y el sentido de la lista cambian según el entorno de ejecución, pero en todos los casos empiezas a leer por la línea que muestra un nombre de archivo escrito por ti.
El log es el registro, con la hora, de lo que ocurre mientras el programa funciona
El texto que hemos visto hasta aquí solo se puede leer en pantalla cuando ejecutas el programa en tu computadora.
En un servidor público no se muestra en la pantalla del usuario, porque mostrarlo le da pistas a un atacante.
| Un mismo fallo | Cuando lo ejecutas en tu computadora | Después de publicarlo |
|---|---|---|
| Tipo de error | La línea TypeError: | La línea ERROR del log |
| Dónde se detuvo | Las líneas que empiezan por at | Las líneas at que quedan en el log |
| Hora en que ocurrió | Justo después de escribir el comando | La hora al principio de la línea |
| Lo que ve el usuario | Todo el texto en la misma pantalla | Solo un aviso breve |
Lo que aparece en la columna de la derecha es el log (log; el registro de lo que ocurre mientras el programa funciona, escrito junto con la hora).
No solo los errores: las solicitudes recibidas y el procesamiento que salió bien también se enumeran línea a línea, en el orden en que ocurrieron.
Al recibir el aviso de que una reserva no se puede guardar, abres el log de my-app.
Alrededor de esa hora estaban estas tres líneas.
2026-09-03 10:12:04 INFO se aceptó el alta de la reserva id=182
2026-09-03 10:12:05 ERROR falló el guardado de la reserva id=182
2026-09-03 10:12:05 ERROR se agotó el tiempo de conexión con la base de datos
Dentro de una línea, las cosas también van en un orden fijo: hora, nivel de log y contenido.
Una línea de log
2026-09-03 10:12:05
- Cuándo ocurrió
- La hora que das en tu pregunta sale de aquí
ERROR
- Qué gravedad tiene el suceso
- Esta categoría se llama nivel de log
falló el guardado de la reserva id=182
- Qué ocurrió
- Aquí también se pueden escribir pistas como id=182
El nivel de log (log level; la categoría que indica la gravedad del suceso de esa línea) que hay en medio te permite extraer y leer solo las líneas graves.
Los nombres y el número de categorías cambian según la biblioteca, pero en todas coincide esto: están ordenadas de los registros leves a los graves, y un ajuste decide a partir de qué nivel se conservan.
Los logs del servidor se escriben en un archivo o se envían a un servicio que los recopila para conservarlos.
Leer solo el final de un archivo se trata en Ver el contenido de archivos — cat / head / tail / wc.
Dónde mirar lo decide el lado en el que se detuvo.
Si se detuvo en la caja de la izquierda, mira la consola del navegador; si se detuvo en la caja de la derecha, mira el log del servidor.
Después de publicar, lo que lees es el log
El texto que en tu computadora aparece en pantalla, después de publicar queda en el log del servidor.
Una línea de log lleva hora, nivel de log y contenido, así que, cuando encuentres la línea ERROR, lee las líneas de alrededor para ver qué estaba pasando.
Al preguntar, cuenta 4 cosas: el texto completo, los pasos para reproducirlo, el entorno y la hora
Si solo dices «me ha salido un error», quien responde tiene que empezar por preguntarte de nuevo.
No puede ver tu computadora, así que lo decisivo es si puede crear ese mismo estado en su propia máquina.
La segunda cosa, los pasos para reproducirlo (steps to reproduce; la secuencia de acciones que vuelve a crear el mismo estado), es lo primero que pide quien responde.
Enumera en orden en qué pantalla estabas, qué escribiste y qué pulsaste, y añade si ocurre todas las veces.
Las cuatro cosas se pegan juntas en un solo bloque, no se envían por separado.
Antes de pegarlas, comprueba que no se hayan colado nombres de destinos de conexión ni claves de API.
El cuerpo de la pregunta
El texto completo que apareció
- Desde la línea TypeError hasta las líneas at
- No recortes solo la última línea
Pasos para reproducirlo
- Elegí 12/24 18:00 en la pantalla de reserva
- Pulsé el botón de registro
Dónde lo ejecutaste
- my-app en tu computadora o el servidor público
- La línea con la que lo ejecutaste, como node app.js
Hora en que ocurrió
- 2026-09-03 10:12:05
- Decide qué parte del log hay que mirar
A veces no funciona como esperabas aunque no aparezca ningún texto de error.
La pantalla se queda en blanco y no pasa nada, o sale un resultado pero con un valor distinto.
En estos casos, busca en qué punto del log se cortan los registros.
Con las 4, la otra persona puede crear el mismo estado
Hay que contar cuatro cosas: el texto completo que apareció, los pasos para reproducirlo, dónde lo ejecutaste y la hora en que ocurrió.
Todas hacen falta para que quien responde vuelva a crear el mismo estado, así que pega el texto tal cual sin recortarlo y, antes de pegarlo, comprueba solo que no se hayan colado valores secretos.
QUIZ
Verificación de conocimientos
Responde cada pregunta una a una.
Pregunta 2Cuando ocurre un error en un servidor público, ¿dónde puedes leer los detalles?
Pregunta 3Cuando preguntas por un error, ¿qué información necesita quien responde para crear el mismo estado?