Creo que todos hemos visto esto. Los principiantes hacen preguntas sobre Stack Overflow que siguen el esquema básico ...
Estoy tratando de hacerlo (descripción muy vaga del objetivo) pero no funciona / recibo un error / excepción. ¡Por favor ayuda!
¿No es extraño que tantos de ellos parezcan innecesarios pegar el mensaje de error?
Me pregunto cuál es la psicología de esto. ¿Qué tienen los mensajes de error que hacen que las personas inicialmente asuman que son inútiles y que no vale la pena prestarles atención?
La respuesta que estoy buscando no es "no entienden el mensaje de error". Eso no explica por qué no considerarían decirle a nadie más que podría entenderlo.
Creo que si es un verdadero principiante, hay muchas posibilidades de que no sepan que hay un mensaje de error. Solo saben que no se ejecuta y que hay un error. Por ejemplo, en Visual Studio, es posible que no vean esa parte de la pantalla.
Básicamente, no saben qué parte de la información que tienen disponible es útil para descubrir cuál es el problema. Si lo hicieran, habría una mejor posibilidad de que pudieran arreglarlo ellos mismos y no preguntar sobre eso en primer lugar.
fuente
Creo que hacer preguntas y solucionar problemas es una habilidad que debe aprenderse, y para los desarrolladores profesionales, es una habilidad importante que simplemente no se enseña con la suficiente frecuencia.
Así como el código que escribes cuando comienzas en esta profesión será horrible en comparación con el código que escribes hoy, las preguntas que hagas serán terribles en comparación con la forma en que las haces hoy.
Cuando comienzas, es fácil sentirse abrumado por toda la información que estás aprendiendo y cuando las cosas no van a planearse, es difícil saber qué información es relevante y qué no. ¡Esta es una gran parte de la razón por la cual los principiantes no pueden resolver el problema por sí mismos en primer lugar!
fuente
Esto se aplica más en IRC que en sitios web en línea como Stack Overflow, que es mucho más raro.
Creo que el razonamiento detrás de esto es que las personas se sienten mejor si saben que una persona en particular está interesada en su problema y está dispuesta a ayudarla. Entonces comienzan diciendo que tienen un problema, pero no entran en detalles hasta que alguien les pregunte, porque temen que de lo contrario no obtendrán una respuesta de todos modos.
A veces (no en el caso de errores del compilador) este comportamiento realmente tiene sentido. Si tengo un gran problema complicado, me aseguraré de que haya alguien escuchando antes de escribir una larga explicación que nadie leerá.
fuente
Debido a que los errores / excepciones del compilador requieren que sepa qué está haciendo mal para solucionarlo. Son para programadores que pasan por alto las cosas, no para las personas que no las entienden.
Tampoco son siempre los más obvios. Un error como "inesperado si" no es tan intuitivo. "Pero eso si debería estar allí" es la respuesta de un novato. Un programador más experimentado sabe que eso significa que ha olvidado el punto y coma en la línea anterior .
fuente
No creo que sean solo novatos. Tengo compañeros de trabajo con años de experiencia que parecen solo mirar el número de línea cuando reciben un error del compilador, luego intentan averiguar el resto ellos mismos (a menudo probando vudú como "agreguemos paréntesis" o "separemos esto" en dos declaraciones ").
Mi sospecha es que esto proviene de no tener una comprensión profunda de las reglas del lenguaje, por lo que la descripción generalmente densa del error no tiene mucho significado.
expression must be a modifiable lvalueque parece ser información bastante inútil si realmente no sabe lo que es un valor-I es.fuente
Bueno, para mí, era un joven lleno de fallos en el software de Windows 95 con mensajes de error completamente impenetrables que generalmente terminaban con unas 150 líneas de hexadecimales.
Revivo la misma experiencia cada vez que obtengo un buen seguimiento críptico de la pila de Java que contendrá 40 líneas de basura del compilador y errores de Hibernate, y muy oculto entre ellos está la referencia real de dónde está el error en mi aplicación.
La razón por la que las personas ignoran los mensajes de error y los seguimientos de la pila es a menudo los mensajes de error y los seguimientos de la pila son desproporcionadamente complicados en comparación con la complejidad del problema. No hay razón para tirar 150 líneas de basura a través de mi pantalla cuando pierdo un punto y coma.
fuente
Estoy enseñando algunos cursos en Linux para Junior Sysadmins, y Programando con PHP y Mysql. La mayoría de los estudiantes en PHP saben que hay un error porque ven el mensaje feo en la pantalla. Pero parecen incapaces de leerlo. Por lo general, voy a su pantalla cuando me dicen que algo no funciona, leo el error en la pantalla, les digo que lo lean, enfatizo el archivo y la línea anotados en el error y les digo que miren allí. Corrigen el error, pero cuando aparece otro error, se aplica el mismo procedimiento ... suspiro ...
Para el curso de Linux, a veces ni siquiera notan el error. Ingresan algún comando, aparecen algunas líneas en la pantalla y continúan con el siguiente comando. Cuando algunos comandos luego notan que algo no está funcionando y levanto la mano, subo, desplazo hacia arriba la consola y señalo un comando que salió con un error debido a parámetros incorrectos o lo que sea. Su cara: sorpresa. Entonces, la parte fácil para mis estudiantes de Linux fue hacerles notar cuando ocurre un error, usando alguna modificación del indicador bash para que sea diferente cuando aparece un error, como este . Ahora, pídales que lean el mensaje de error una vez que lo vean, esa es una batalla diferente (igual que con los estudiantes de PHP) ...
fuente
Creo que simplemente no están acostumbrados a pensar en códigos de error, y para cuando llegan al lugar donde deberían darlos, ya sienten que explicaron completamente el problema y, por lo tanto, es menos probable que se detengan y piensen si deberían dar información adicional.
Hacer una pregunta implica algunas etapas, y están más lógicamente organizadas en este orden:
El informe post mortem es donde estará el mensaje de error, y está al final. Cuando los novatos llegan a este punto, se encuentran al final del desafío mental de explicar su problema y es más probable que pierdan algo (para un novato, hay un problema de sobrecarga de información). Además, en este punto ya sienten que describieron todos los aspectos del problema y tienen hábitos pasados que les impiden recordar los códigos de error: después de todo, otros campos de la vida no tienen códigos de error, por lo que no están acostumbrados a Piensa en ellos.
También puede ser que incluso si recuerdan los códigos de error, parecen demasiado crípticos para ser de uso real. ¿Qué es el error 034982? ¿Esto realmente significa algo para alguien? ¿Y realmente agrega algo a esa descripción detallada de lo que estaba haciendo, cómo lo estaba haciendo y cómo falló? Surly esta información se destaca por sí misma.
fuente
Porque para la mayoría de los idiomas, la mayoría de los mensajes de compilación / tiempo de ejecución no tienen ningún sentido. (C ++ y Java especialmente, ¡te estoy mirando!) Corregir los errores tiende a ser bastante bajo en la lista de prioridades de un diseñador de idiomas. Por lo general, hacer que las cosas funcionen correctamente es una prioridad mayor, y muchas veces no se molestan en pulir los pequeños detalles.
Esa es una de las razones por las que disfruto trabajar en Delphi. Todo el lenguaje está lleno de atención a los pequeños detalles, incluidos los errores. Los mensajes del compilador tienen sentido. Los mensajes de error en tiempo de ejecución tienen sentido. Las huellas de pila tienen sentido. Es una de las cosas que lo convierte, con mucho, en el lenguaje más fácil de depurar con el que he trabajado.
fuente