TL;DR

Este artigo vai lhe dar algumas dicas sobre o mais importante passo ao depurar (ou “debugar”) sua aplicação: Ler os erros. Parece bobagem, mas muitos desenvolvedores falham aqui. Eles vêem – e não leem – a mensagem de erro e vão diretamente ao Google ou Stack Overflow procurar por respostas diretas. Essa abordagem pode funcionar quando você está apenas executando uma aplicação que você baixou e instalou no seu servidor web, porém não lhe dirá nada quando for no próprio código. Mas o erro por si só aponta o que está acontecendo e aonde (em qual linha). Então, LEIA OS ERROS!

INTRODUÇÃO

Inúmeras vezes eu vi posts no Stack Overflow onde pessoas perguntam algo como isso:

Eu tenho este código “…” mas não funciona! Como corrigir isso?

Ele não funciona? Só isso? Existem duas alternativas para um código não funcionar: ele joga uma mensagem de erro na tela, ou ele não se funciona como deveria (tem resultados diferente do que você espera), correto? Neste artigo, vamos aprender como lidar com a primeira situação, LENDO OS ERROS.

O ERRO TE CONTA COISAS IMPORTANTES

Lembro disso. O erro sempre estará apontando o seu erro e tentando explicar à você que conhece (ou deveria conhecer) o código.

Os erros PHP tem as seguinte estrutura:

PHP Notice: Undefined variable: name in index.php on line 5 
\________/ \_______________________/ \__________/ \_______/ 
(1)         (2)                       (3)          (4) 
1 - Gravidade do erro 2 - Mensagem de erro 3 - Nome do arquivo 4 - Linha

Apenas lendo a mensagem de erro (2) nós podemos perceber que estamos chamando uma variável que não existe, correto? Para corrigir, precisamos saber em qual arquivo (3) e qual linha (4) o erro ocorre.

Para por este erro em contexto, vamos ver o código:

<?php

$myName = "Elias Soares";

$explodedName = explode(' ', $name);

Agora nós podemos claramente ver que na linha 5, estamos passando $name como parâmetro, e o PHP está dizendo que esta variável não existe. Neste caso, basta olhar para a linha anterior para ver que chamamos a variável de $namee não de $explodedName.

Ótimo, nós lemos nossa primeira mensagem de erro, e agora?

LEIA A STACK TRACE (RASTROS DA PILHA, EM PORTUGUÊS)

Em uma aplicação complexa, algumas vezes você pode não saber porque uma determinada parte do código está sendo chamada, ou como aquele valor foi passado como parâmetro ali.

Vamos ver este exemplo:

<?php

function splitMyName(string $name) {
    return explode(' ', $name);
}

function extractNameFromData(array $data) {
    return splitMyName($data['role']);
}

$data = [   
    'id' => 110690,
    'name' => 'Elias Soares',
    'role' => null
];

$name = extractNameFromData($data);

echo $name[0];

Ao executar este código, vamos receber o seguinte erro:

Fatal error: Uncaught TypeError: Argument 1 passed to splitMyName() must be of the type string, null given, called in /var/www/public/demo.php on line 8 and defined in /var/www/public/demo.php:3 Stack trace: #0 /var/www/public/demo.php(8): splitMyName(NULL) #1 /var/www/public/demo.php(17): extractNameFromData(Array) #2 {main} thrown in /var/www/public/demo.php on line 3

Perceba que agora após a mensagem de erro, nós temos uma Stack Trace. A stack trace é útil para entender quem está chamando determinada função que causa aquele erro. A pilha é reversa, o que significa que a posição #0 é a linha de código aonde ocorreu o erro.

Aqui nós podemos ver que a função splitMyName está sendo chamada com NULL como parâmetro, dentro da função extractNameFromData(). Nós também podemos ver que extractNameFromData() está sendo chamada na linha 17.

Agora imagine uma aplicação complexa, aonde a pilha é tão grande quando a aplicação em si, e a função é chamada por vários lugares. É praticamente impossível (a menos que tenha memorizado todo seu código) saber porquê aquela função está sendo chamada com o parâmetro errado. Nós precisamos seguir os rastros da pilha. Este é o ensinamento aqui.

Se sua função parece ok, alguém está bagunçando os parâmetros. Pode ser que a função seja chamada no mesmo arquivo apenas uma vez, ou várias vezes, ou até mesmo em vários arquivos. Vai ser mais fácil se você souber seguir os rastros da pilha. Você vai apenas seguir o caminho que o PHP lhe dá.

CONCLUSÃO

Aprender a ler os erros é muito importante se você quer ser um programador bom e eficiente. Vai lhe poupar tempo precioso que você pode usar para dormir. 😀

Esta série terá mais alguns posts, eu planejo explicar no próximo post como depurar sua logica quando não houverem erros.