Por que os novos programadores parecem ignorar as mensagens de erro do compilador / exceção de tempo de execução? [fechadas]

Eu acho que todos nós vimos isso. Os iniciantes fazem perguntas no Stack Overflow que seguem o esboço básico ...

Estou tentando fazer (descrição muito vaga do objetivo), mas não funciona / recebo um erro / exceção. Por favor ajude!

Não é estranho que muitos deles pareçam desnecessários colar a mensagem de erro?

Eu me pergunto qual é a psicologia disso. O que há nas mensagens de erro que levam as pessoas a assumir inicialmente que são inúteis e que não merecem atenção?

A resposta que estou procurando não é "eles não entendem a mensagem de erro". Isso não explica por que eles não considerariam contar a alguém que possa entender isso.

Eu acho que a verdadeira razão é que os usuários comuns de computador, mesmo que se tornem programadores, estão condicionados a acreditar que não podem fazer nada sobre erros. Pense nisso. O que os tipos não programadores fazem quando encontram uma mensagem de erro enigmática *? Eles podem lê-lo, mas nove em cada dez simplesmente o descartam e tentam novamente. Somente se falhar consistentemente, eles procurarão.

Portanto, ao começar a aprender a programar, as pessoas não percebem imediatamente que o erro que estão recebendo contém informações úteis sobre como corrigi-lo; e sim, embora os erros do compilador possam ser quase ilegíveis, mesmo para o profissional treinado (estou olhando para você, metaprogramação de modelos em C ++), pelo menos eles fornecem um ponto de partida geral e depois que você vê o mesmo erro algumas vezes , você sempre saberá o que fez para causar isso.

* Honestamente, no entanto, a maioria das mensagens de erro se assemelha a Joe Average como "Erro X2412: Não é possível estabelecer dongledash interplataformas frobnicatórias: verifique as configurações de bandersnatch ou entre em contato com o administrador do sistema".

Eu acho que se for um iniciante de verdade, há uma boa chance de que eles não saibam que há uma mensagem de erro. Eles sabem apenas que não funciona e que há um erro. Por exemplo, no Visual studio, eles podem não ver essa parte da tela.

Basicamente, eles não sabem qual parte das informações disponíveis são úteis para descobrir qual é o problema. Se o fizessem, haveria uma chance melhor de consertar eles mesmos e não perguntar sobre isso em primeiro lugar.

Acho que fazer perguntas e solucionar problemas é uma habilidade que precisa ser aprendida e, para desenvolvedores profissionais, é uma habilidade importante que simplesmente não é ensinada com bastante frequência.

Assim como o código que você escreve quando você começa nesta profissão vai ser horrível em comparação com o código que você escreve hoje, as perguntas que você faz serão terríveis em comparação com o que você faz hoje.

Quando você começa, é fácil ficar impressionado com todas as informações que você está aprendendo e quando as coisas não estão indo bem, é difícil saber quais informações são relevantes e quais não são. Essa é uma grande parte da razão pela qual os iniciantes não conseguem resolver o problema por si mesmos!

Isso se aplica mais ao IRC do que a sites on-line, como o Stack Overflow, que é muito mais raro.

Penso que o raciocínio por trás disso é que as pessoas se sentem melhor se souberem que uma pessoa em particular está interessada em seu problema e está disposta a ajudá-la. Então, eles começam dizendo que têm um problema, mas não entram em detalhes até que alguém pergunte, porque temem que, caso contrário, não recebam resposta.

Às vezes (não no caso de erros do compilador) esse comportamento realmente faz sentido. Se eu tiver um grande problema complicado, certificarei-me de que haja alguém ouvindo antes de escrever uma longa explicação que ninguém lerá.

Como os erros / exceções do compilador exigem que você saiba o que está fazendo de errado para corrigi-lo. Eles são para programadores que ignoram coisas, não para pessoas que não as entendem.

Eles também não são sempre os mais óbvios. Um erro como "inesperado se" não é tão intuitivo. "Mas que se deveria estar lá" é a resposta de um novato. Um programador mais experiente sabe que isso significa que ele esqueceu o ponto e vírgula na linha anterior .

Eu não acho que são apenas novatos. Tenho colegas de trabalho com anos de experiência que parecem olhar apenas para o número da linha quando recebem um erro do compilador e depois tentam descobrir o resto (geralmente tentando vodu como "vamos adicionar parênteses" ou "vamos acabar com isso"). em duas declarações ").

Minha suspeita é que isso se origina de não ter um entendimento profundo das regras da linguagem, de modo que a descrição geralmente densa do erro não tenha muito significado. expression must be a modifiable lvalueParece que informações bastante inútil se você realmente não sei o que é um lvalue é.

O que há nas mensagens de erro que levam as pessoas a assumir inicialmente que são inúteis e que não merecem atenção?

Bem, para mim, era um jovem cheio de falhas do software Windows 95 com mensagens de erro completamente impenetráveis ​​que geralmente terminavam com cerca de 150 linhas de hexadecimais.

Eu revivo a mesma experiência toda vez que recebo um bom rastreamento de pilha enigmático que contém 40 linhas de porcaria do compilador e erros de Hibernate, e escondido muito bem entre eles está a referência real de onde está o erro no meu aplicativo.

O motivo pelo qual as pessoas ignoram as mensagens de erro e os rastreamentos de pilha geralmente é que as mensagens de erro e os rastreamentos de pilha são desproporcionalmente complicados em comparação com a complexidade do problema. Não há razão para liberar 150 linhas de porcaria na minha tela quando falto um ponto e vírgula.

Estou ministrando alguns cursos sobre Linux para Junior Sysadmins e Programação com PHP e Mysql. A maioria dos estudantes de PHP sabe que há um erro porque vê a mensagem feia na tela. Mas eles parecem incapazes de lê-lo. Geralmente eu vou para a tela deles quando eles me dizem que algo não está funcionando, eu leio o erro na tela, digo a eles para lê-lo, enfatizando o arquivo e a linha anotada no erro e digo para eles procurarem lá. Eles corrigem o erro, mas quando outro erro aparece, o mesmo procedimento se aplica ... suspiro ...

Para o curso Linux, às vezes eles nem percebem o erro. Eles inserem algum comando, algumas linhas aparecem na tela e continuam com o próximo comando. Quando alguns comandos mais tarde, eles finalmente percebem que algo não está funcionando e levantam as mãos, eu subo, role o console e aponte para um comando que saiu com um erro devido a parâmetros incorretos ou o que quer que seja. O rosto deles: surpresa. Portanto, a parte mais fácil para meus alunos de linux foi notá-los quando ocorreu um erro, usando algumas modificações no prompt do bash para torná-lo diferente quando um erro aparecer, como este . Agora, faça com que eles leiam a mensagem de erro quando a virem, é uma batalha diferente (a mesma que acontece com os estudantes de PHP) ...

Acredito que eles não estão acostumados a pensar em códigos de erro e, quando chegam ao local em que deveriam dar, já sentem que explicaram completamente o problema e, portanto, têm menos probabilidade de parar e pensar se eles devem fornecer informações adicionais.

Fazer uma pergunta envolve alguns estágios, e eles são mais organizados logicamente nesta ordem:

1. você precisa descrever o que estava fazendo
2. você precisa descrever como você estava fazendo isso
3. você precisa descrever o que aconteceu quando falhou (ou como falhou)
4. você precisa fornecer o relatório post mortem

O relatório post mortem é onde estará a mensagem de erro e está no final. Quando os novatos chegam a esse ponto, eles estão no final do desafio mental de explicar seu problema e têm maior probabilidade de perder alguma coisa (para um novato, há um problema de sobrecarga de informações). Além disso, nesse ponto, eles já sentem que descreveram todos os aspectos do problema e têm hábitos passados ​​que os impedem de se lembrar dos códigos de erro: afinal, outros campos da vida não têm códigos de erro, portanto não estão acostumados a pense neles.

Também pode ser que, mesmo que se lembrem dos códigos de erro, eles pareçam muito enigmáticos para serem realmente usados. Apenas o que é o erro 034982? Isso realmente significa alguma coisa para alguém? E isso realmente adiciona algo a essa descrição detalhada do que eu estava fazendo, como estava fazendo e como falhou? Certamente, essa informação se destaca.

Porque para a maioria dos idiomas, a maioria das mensagens do compilador / tempo de execução não faz sentido. (C ++ e Java, especialmente, estou olhando para você!) A correção dos erros tende a ser bastante baixa na lista de prioridades de um designer de linguagem. Conseguir que as coisas funcionem corretamente funcione normalmente é uma prioridade maior, e muito tempo elas não se preocupam em polir os pequenos detalhes.

Essa é uma das razões pelas quais gosto de trabalhar no Delphi. O idioma inteiro está cheio de atenção aos pequenos detalhes, incluindo os erros. Mensagens do compilador fazem sentido. Mensagens de erro de tempo de execução fazem sentido. Rastreios de pilha fazem sentido. É uma das coisas que a torna, de longe, a linguagem mais fácil para depurar com a qual já trabalhei.