Quando os iniciantes chegam ao ponto de depuração, especialmente o código de um terceiro / biblioteca ou quando eles se juntam a uma equipe com uma base de código / projeto existente. Eles costumam ficar intimidados se o compilador emitir muitos erros (talvez em uma pequena alteração). Eles podem ir imediatamente para um programador mais experiente para pedir ajuda.
Um pequeno conselho para tais casos:
Acalme-se.
Em muitos casos, observe apenas o primeiro erro (role para cima!). Freqüentemente, um pequeno problema (como a falta de um ponto e vírgula) leva a um monte de ruído. Lembre-se de olhar também a linha anterior ao número da linha incorreto no código que o compilador relata. (Eu vi uma sessão WWDC sobre as ferramentas baseadas em llvm do Xcode 4+ que fez algumas melhorias sobre a facilidade de mensagens de erro e suas localizações, mas a dica ainda pode se aplicar a outras ferramentas.)
Isso pode ser bastante óbvio – tente corrigir o (s) problema (s) sistematicamente. Do primeiro ao último, ou se você perceber que pode agrupar certos problemas, poderá resolvê-los primeiro. Também seria um bom momento para submeter as alterações de código ao controle de versão quando você consertar uma classe de erros (você está usando um sistema de controle de versão distribuído que não afeta o resto da equipe até que esteja pronto para empurrar, certo?).
Em algo como C ++, você pode querer compilar / reconstruir depois de resolver cada problema – você pode notar que o número de erros é reduzido em mais de um para cada correção. Por exemplo, se você notar um monte de undefined symbol ...mensagens, a possível correção de incluir uma biblioteca como uma entrada para o vinculador pode eliminar muitas mensagens de uma vez (ou todas se houver apenas uma dependência ausente).
Parece óbvio novamente, mas leia a mensagem de erro com atenção. É muito provável que esteja dizendo exatamente o que você precisa fazer. As mensagens muitas vezes podem soar como se um computador ( que você pode considerar como não um falante nativo de inglês ) está tentando dizer algo – acho que no interesse de manter as mensagens de erro curtas e / ou ajustar um limite histórico de 80 caracteres, as mensagens podem não estar completas frases, mas eles passam a mensagem. Além disso, você realmente deseja ler uma frase longa quando deseja apenas uma ideia rápida?
divide by zero error at line ... file ...– isso diz completamente o que há de errado, não é? A mensagem terá um onde e o quê . Se a mensagem não fizer muito sentido para você depois de pensar um pouco sobre ela, tente procurá-la na documentação da cadeia de ferramentas ou online em geral. O mesmo se aplica a erros e exceções em tempo de execução.
” Estou recebendo um IllegalArgumentException! ”
” Bem, para qual método você passou um argumento ilegal? ”
Depois de pesquisar, pense em como ele se aplica à seção do código onde o erro é relatado ( Estou dividindo algum números lá? Um deles é zero? É o denominador? Espere, isso não está definido!) Obviamente, separe as partes fixas da mensagem de erro das partes variáveis (número da linha e nome do arquivo no exemplo acima) ao procurá-lo – você não precisa encontrar informações sobre alguém que teve o mesmo problema na mesma linha de código .
Outra coisa, preste atenção aos avisos . Muitas vezes os desenvolvedores os ignoram – “Ah, é apenas um aviso, não me impede de prosseguir”. Provavelmente é algo que acontecerá em tempo de execução. Muito pior. Enquanto estamos falando sobre avisos de limpeza, deixe-me acrescentar conselhos para usar ferramentas de análise estática .
Finalmente, os erros são uma coisa boa (TM) . Especialmente aquele de uma ferramenta de estágio inicial como um compilador; Corrija os problemas agora, antes que seu código trave em tempo de execução! A ideia também pode estar relacionada a “falhe cedo, falhe rápido”. É assim que você aprende e segue em frente para melhorar. Erros / Avisos evitam que você “fique às cegas” (Logs / rastreamentos também são ótimos salva-vidas para depuração post-mortem em um ambiente de produção). Em vez de adivinhar o que aconteceu, pelo menos você tem um ponto de partida concreto para começar a lidar com um problema.
Artigo recomendado: Introdução à depuração por Richard Fine em gamedev.net Para
onde ir a partir daqui? Talvez você queira começar a pensar sobre o desenvolvimento orientado a testes .