Este tutorial também foi postado originalmente no Fórum iMasters, e foi criado por mim juntamente com outros membros do fórum.
É muito importante fazer tratamento de erros em nossas aplicações. Falhas e mensagens de erro pouco amigáveis contribuem com a taxa de rejeição dos sites. Afinal, se uma aplicação gera erro, nós raramente acessamos o site novamente.
Além disso, mensagens de erro padrões das linguagens de programação costumam mostrar caminhos de arquivos. Isso pode ser uma grande falha de Segurança. Outro motivo para fazer um bom tratamento de erros em suas aplicações.
Fonte: http://forum.imasters.com.br/topic/229485-tratamento-de-erros/
Sumário
1. O que é Tratamento de Erros
2. Boas maneiras para programar sem erros
2.1 Programar de maneira errada
2.2 Esconder Erros
2.3 Falta de uma lógica mais apurada e desenvolvida
2.4 Não pensar nos usuários
2.5 Falta de conhecimento da linguagem com a qual se está programando
2.6 Falha no Hardware
3. Como debugar um script
4 – Validações para evitar erros
5. Tratando erros com Exceções
1. O que é tratamento de erros
Tratar um erro nada mais é do que preparar para rodar em qualquer situação ou, se não for possível, avisar por que não pôde ser executado. Tratando um erro você pode esperar uma situação e contorná-la ou, se não tiver jeito, finalizar a execução de uma forma segura e que não deixe o usuário sem saber o que está acontecendo. Ao fazer um tratamento de erros adequado, você pode preparar mensagens personalizadas para avisar os usuários que o sistema não pôde ser executado e notificar o erro ao administrador do site, para ele saber exatamente o que aconteceu e como proceder para corrigir o problema. Além disso, é útil para criação de estatísticas de erros.
2. Boas maneiras para programar sem erros
Além de fazer um tratamento de erros adequado, você precisa programar de uma maneira que evite erros. Existem vários meios de gerar erros no seu sistema e, sabendo como evitá-los, você deixar seu sistema mais profissional e à prova de falhas. Possíveis causas de erros no sistema:
Programar de maneira errada
Esconder erros
Falta de uma lógica mais apurada e desenvolvida
Não pensar nos usuários
Falta de conhecimento na linguagem com a qual se está programando
Falha por parte de hardware
Explicarei um pouco sobre cada um.
2.1 Programar de maneira errada
Esta tem suas principais causas: preguiça, pressa, falta de planejamento e/ou falta de conhecimento. A preguiça é porque na maioria das vezes o programador não quer saber como faz, mas, sim, entregar o sistema o mais rápido possível. Ele procura scripts prontos na Internet, só edita algumas coisas fáceis e acaba fazendo uma salada mista de vários sistemas prontos, tudo mal feito. O resultado é um sistema cheio de erros. Quanto mais o programador estudar e procurar entender para fazer seus sistemas, mais eles ficarão enxutos e livres de erros.
A pressa é outra vilã. O programador acaba fazendo um monte de gambiarras e pensa assim: “Ah, depois de entregar o sistema eu arrumo os erros com calma. O mais importante é entregar no prazo!”, e acaba nunca arrumando. Falta de planejamento também é muito ruim e acontece quando o programador mal pegou o serviço e já quer fazer tudo de uma vez, sem pensar em como o desenvolverá. Como resultado, acaba fazendo o sistema, depois o banco de dados, e depois sai costurando as falhas até deixar tudo funcionando. Tenha calma e não se apresse em fazer. Em um sistema bem feito, 70% dele é planejamento e o restante, escrever os códigos, modelar um banco de dados de forma correta, etc.
Já a pior das causas é a falta de conhecimento, pois é comum pessoas mal saberem o que é um HTML e já querem programar em PHP. Em alguns casos, conseguem até clientes e sempre aparecem desesperadamente nos fóruns pedindo ajuda para fazer um sistema para eles. Consequentemente nunca farão um sistema bem feito, até aprenderem a fazê-los por conta própria. Outros programadores têm até certo conhecimento, mas não o usa, enquanto outros chegam a um limite e param, acreditando que não precisam aprender mais nada. Aí surgem com aquela frase: “Em time que está ganhando não se mexe!”. Já vi programadores com 40 anos nas costas que usam o mesmo sistema que aprenderam a fazer no passado. Não querem evoluir ou aprender coisas novas, e aí acabam escondendo erros em vez de tratá-los.
Existem várias maneiras de se esconder erros no PHP e muitos têm abusado desses recursos. Não se devem esconder erros!. Claro que num site já publicado você não pode deixar que usuários vejam erros do seu sistema, mas nem por isso se deve escondê-los. Se o sistema tem falhas deixe uma mensagem avisando que logo ele estará funcionando, em vez disso, por exemplo, mostrando um erro grotesco e que não significa nada ao usuário leigo, além de expor informações internas do seu sistema, como por exemplo Warning: mysql_connect() [function.mysql-connect]: Access denied for user ‘root’@’localhost’ (using password: NO) in…
Muitas vezes eu falo que esconder erros é a mesma coisa que varrer a sujeira para debaixo do tapete. Não vou entrar em detalhes na parte de boas maneiras ao programar, porque já publicamos um artigo sobre isso (leia-o aqui).
2.2 Esconder Erros
Agora vou explicar como esconder um erro do PHP e como fazer para mostrar mensagens personalizadas. Os erros têm que ser escondidos em certos casos porque senão o PHP acaba mostrando mensagens de erros para o usuário, por exemplo:
Exemplo 2.2.1 Operadores de controle de erro (retirado do Manual do PHP)
O PHP suporta um operador de controle de erro: o sinal ‘arroba’ (@). Quando ele precede uma expressão em PHP, qualquer mensagem de erro que possa ser gerada por ela será ignorada.
Se o recurso track_errors estiver habilitado, qualquer mensagem de erro gerada pela expressão será gravada na variável global $php_errormsg. Esta variável será sobrescrita em cada erro, assim verifique-a constantemente se você quiser usá-la.
1 2 3 4 5 6 7 8 | <?php /* Erro intencional de arquivo */ $my_file = @file ('arquivo_nao_existente') or die("Falha abrindo arquivo: '$php_errormsg'"); // Isto funciona para qualquer expressão, não apenas para funções: $valor = @$carrinho[$produto]; // você não receberá nenhum aviso se a chave $produto não existir. ?> |
Nota: o operador @ funciona somente em expressões. Uma regra simples para lembrar disso: se você pode pegar o valor de alguma coisa, você pode prefixar isso com o @. Assim, você pode prefixar chamadas de variáveis, funções e include()’s, constantes e afins. Você não pode prefixar definições de funções ou classe, estruturas condicionais como o if, foreach e assim por diante.
Exemplo 2.2.2 Ocultar erro em conexões com banco de dados
Usando o @ você pode ocultar erros de conexões com o banco de dados:
1 2 3 | <?php @mysql_connect("localhost", "root") or die("Mensagem de erro"); ?> |
Usando o @ podemos ocultar a mensagem de erro do PHP, mas devemos, ainda, informar o usuário e exibir uma mensagem de erro personalizado, podendo usar CSS, imagens etc. O mesmo vale para erros na abertura de arquivos ou envio de e-mails.
Outra maneira de ocultar erros é editando o PHP.INI na linha “display_errors = off”. Muitos programadores, por não saberem configurar corretamente o PHP.INI, deixam-no no padrão de instalação e, dependendo da versão do PHP, o display_errors está em “off”. O que recomendo é deixar em “on”, caso contrário, o PHP não irá mostrar os erros, caso ocorram. Eu vejo erros comuns pelos fóruns, tipo esse:
Exemplo 2.2.3 Índice não encontrado
1 | $val = $_POST[val]; // erro não delimitou uma string com aspas ou apóstrofos |
Daí eu falo para o usuário que ele precisa delimitar as strings com aspas, por exemplo, $_POST[“val”]. Mas o usuário acaba comentando: “Mas assim também funciona e não tem erro!”. Isso acontece porque o display_errors dele esta em “off” e por isso não consegue perceber o erro. O PHP entende, conforme o exemplo acima, que val é uma constante. Não a encontrando, assume como uma string e exibe um erro do tipo E_NOTICE.
Exemplo 2.2.4 Ocultar erros com error_reporting() (retirado do Manual do PHP) A função error_reporting() define a diretiva error_reporting em tempo de execução. O PHP tem vários níveis de erros, usando essa função você pode definir o nível durante a execução do seu script. error_reporting() define o nível de erros que o PHP irá reportar, e retorna o nível antigo. O parâmetro nível pode usar um bitmask, ou constantes. É fortemente recomendado que você use constantes para assegurar compatibilidade com futuras versões. Como níveis de erros podem ser adicionados, o intervalo das constantes pode crescer, então os níveis de erros indicados anteriormente por inteiros podem não funcionar como esperado.
Exemplo 1. Exemplos error_reporting()
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | <?php // Desativa o relatório de todos os erros error_reporting(0); // Reporta erros simples error_reporting(E_ERROR | E_WARNING | E_PARSE); // Reportar E_NOTICE pode ser bom também (para reportar variáveis não iniciadas // ou erros de digitação em nomes de variáveis ...) error_reporting(E_ERROR | E_WARNING | E_PARSE | E_NOTICE); // Reportar todos os erros exceto E_NOTICE // Este é o valor padrão no php.ini error_reporting(E_ALL ^ E_NOTICE); // Reporta todos os erros (bitwise 63 deve ser usado no PHP 3) error_reporting(E_ALL); // O mesmo que error_reporting(E_ALL); ini_set('error_reporting', E_ALL); ?> |
Os níveis de erros disponíveis estão listados abaixo. A descrição deles está em constantes predefinidas.
1 E_ERROR
2 E_WARNING
4 E_PARSE
8 E_NOTICE
16 E_CORE_ERROR
32 E_CORE_WARNING
64 E_COMPILE_ERROR
128 E_COMPILE_WARNING
256 E_USER_ERROR
512 E_USER_WARNING
1024 E_USER_NOTICE
2047 E_ALL
2048 E_STRICT
Atenção
A partir do PHP 5.0.0, E_STRICT com o valor 2048 está disponível. E_ALL NÃO mostra erros do nível E_STRICT.
Recomendo deixar error_reporting(E_ALL), para mostrar todos os tipos de erros.
2.3 Falta de uma lógica mais apurada e desenvolvida
Agora falando sobre lógica! Muitos erros acontecem também por falta de uma lógica correta, ou seja, programam de maneira errada, fazem gambiarra (famosa POG – Programação Orientada à Gambiarras)) ou complicam demais algo que poderia ser mais simples. Já vi muitos usuários não saberem manipular datas, como somar, subtrair, etc. Acabam fazendo cada loucura com uma coisa simples. Falta de lógica pode fazer com que o sistema fique com erros e, por azar, o programador não percebe até que o erro aconteça.
2.4 Não pensar nos usuários
Não pensar nos usuários também pode fazer com que o sistema tenha erros. Um exemplo disso é o programador ter um micro de último tipo, e configurar o PHP.INI a seu gosto, com programas atualizados e acaba desenvolvendo pensando só nele. Esquece que outros usuários que irão usar o sistema não têm o mesmo recurso. Por exemplo: o programador faz um sistema usando PHP 5.2, Apache 2.2.4, Mysql 5 e disponibiliza o sistema para outros usuários e o coitado do usuário baixa o sistema e vai rodar num servidor com PHP 4 e Mysql 3 (a grande maioria dos servidores de hospedagem demoram para se atualizarem). Aí o sistema não funciona e aparecerá um monte de mensagens de erros e o usuário nem sabe o porquê. Não estou falando que não se deve programar usando as últimas versões, mas tem que ver pra qual situação será usado o sistema e verificar se o sistema está apto a rodar na plataforma em que foi instalado.
2.5 Falta de conhecimento da linguagem com a qual se está programando
Falta de conhecimento na linguagem PHP também faz o sistema ter muitos erros. Muitas vezes o usuário é até esforçado, mas por falta de conhecimento não sabe identificar um erro ou um problema e muito menos fazer de um jeito melhor. Acaba pegando scripts prontos para aprender, mas estes também estão sujeitos a erros e o usuário vai querer editar, deixando-o cada vez pior. Por falta de conhecimento na linguagem também acontecem muitos erros de concatenação de strings, tags PHP, ou juntar HTML + PHP, banco de dados, entre outras coisas. Nesse tipo de coisa é muito fácil de cometer erros, principalmente se o usuário for inexperiente.
É importante estudar muito, acompanhar os novos recursos e buscar conhecimento em fontes sérias. Só assim evita-se dor de cabeça ou mesmo a perda de espaço no mercado de trabalho.
2.6 Falha no Hardware
E por último, erros também acontecem independente do sistema estar perfeito ou não. Pode ser que o servidor esteja em manutenção, ou outros problemas relacionados a hardware etc. Por esse motivo que, mesmo você fazendo um ótimo tratamento de erros, o sistema não conseguirá ser executado. Falarei de exceções logo mais à frente.
3. Como debugar um script
Para testar um script e ver se ele está funcionando corretamente, há várias maneiras. A primeira delas é testar num servidor local. Para desenvolver, sempre deixe essas opções configuradas no php.ini:
display_errors = On
display_startup_errors = On
error_reporting = E_ALL
log_errors = On
track_errors = On
register_globals = Off
Via script você pode fazer assim:
1 2 3 4 5 | <?php @ini_set("display_errors", 1); @ini_set("log_errors", 1); @ini_set("error_reporting", E_ALL); ?> |
Em versões do PHP igual ou anterior à 4.2.3 era possível setar a diretiva register_globals via script, mas agora só via PHP.INI ou .htaccess. Via .htaccess é assim:
1 | php_flag register_globals off |
Agora, com tudo preparado, só resta testar o sistema. Existem vários editores com recursos para debugar um script, como por exemplo o PHPEdit da WaterProof, o editor da Zend ou o da Maguma.
4 – Validações para evitar erros
Um bom tratamento de erros precisa prever vários tipos de erros e, pra isso, existem funções específicas, como por exemplo:
file_exists – serve para verificar se um arquivo existe
defined – serve para verificar se uma constante foi definida.
isset – verifica se uma variável existe.
is_array – verifica se a variável é um array
is_resource – verifica se a variável é um resource
is_numeric – verifica se a variável é um número ou uma string numérica.
is_uploaded_file – verifica se o arquivo foi uploaded via HTTP POST.
is_writable – verifica se pode escrever para o arquivo (writable).
version_compare – Compara a versão do php.
extension_loaded – verifica se a extensão foi habilitada.
Com essas funções você pode testar, por exemplo, se um arquivo existe, antes de incluí-lo. Caso não exista, você pára o script e dá um aviso para o usuário. Outro exemplo: antes de gravar um arquivo texto, você verifica se ele pode ser escrito, ou antes de usar uma variável teste, se ela existe com isset()
Outra validação muito importante é validar se o formulário foi enviado, assim evitando erro, por exemplo:
Exemplo 4.1 Verificando se um formulário foi enviado
1 2 3 | if (getenv("REQUEST_METHOD") == "POST") { //...faça tal coisa } |
Se for get só mudar para GET, assim você testa se o formulário foi enviado.
Outra dica importante é testar se a variável existe caso venha de algum formulário:
Exemplo 4.2 Verificando se uma variável foi inicializada
1 | $campo = isset($_POST["campo"]) ? $_POST["campo"] : ""; |
Exemplo 4.2 Incluindo um arquivo sem verificação
De tratamento de erros:
1 2 3 | <?php require "arquivo.php"; ?> |
Mas e se o arquivo nao existir? Iria dar erro, então o mais correto é:
Exemplo 4.3 Incluindo um arquivo com verificação
1 2 3 4 5 | <?php if (file_exists("arquivo.php")) { require "arquivo.php"; } ?> |
Exemplo 4.4 Desabilitando magic_quotes
Programar dependente de magic_quotes não é recomendando, visto que o site ou sistema poderá não funcionar corretamente caso seja hospedado em um servidor com configuração divergente da que foi adotada para os testes locais. Os erros mais comuns são na inserção de valores em um banco de dados. Além disso, a partir do PHP 6, a diretiva magic_quotes_gpc não existirá mais e, por isso, é recomendado programar desabilitando este recurso. Esta diretiva não pode ser alterada através da função ini_set, devendo ser configurada diretamente no PHP.INI ou, se também possível, através do .htaccess, da seguinte forma:
1 | php_flag magic_quotes_gpc Off |
Como alternativa, você pode utilizar a função abaixo:
1 2 3 4 5 6 7 8 9 10 11 12 | function remove_magic_quotes() { if (get_magic_quotes_gpc()) { $_GET = array_map("remove_mq", $_GET); $_POST = array_map("remove_mq", $_POST); $_REQUEST = array_map("remove_mq", $_REQUEST); $_COOKIE = array_map("remove_mq", $_COOKIE); } } function remove_magic_quotes(&$var) { return is_array($var) ? array_map("remove_magic_quotes", $var) : stripslashes($var); } |
Basicamente, a função verifica se a diretiva magic_quotes está habilitada e, então, varre pelos dados dos arrays globais inicializados (enviados por um formulário, por exemplo), eliminando os escapes dos caracteres. Preferencialmente, esta função deve ser chamada num arquivo de inicialização do sistema ou site.
5. Tratando erros com Exceções
A partir da versão 5 do PHP, pode-se tratar erros usando Exceções. Com o uso desse recurso, podemos manipular os erros com mais precisão, facilitando, por exemplo, a criação de um log de erros contendo o nome do arquivo e a linha em que o erro ocorreu.
A classe Exception pode ser extendida a uma outra, viabilizando a personalização de mensagens de erro e a criação de uma classe para cada tipo de exceção. Por exemplo: é possível termos uma classe para manipular erros relacionados a banco de dados, outra para o manuseio de arquivos, de imagens, etc.
Uma exceção deve ser disparada (thrown) dentro de um bloco try{}. Em seguida, deve ser pega (catched) usando o bloco catch{}.
Exemplo 5.1: Usando exceções para capturar um possível erro na conexão com um banco de dados MySQL
1 2 3 4 5 6 7 8 9 10 11 12 | try { //usamos o arroba para ocultar o possível erro retornado pelo PHP @$MySQLi = new MySQLi("localhost", "user", "pass", "db_name"); if (!$MySQLi) { //se conexão falhar throw new Exception("Erro ao realizar a conexão com o banco de dados"); } } catch (Exception $e) { echo $e->getMessage(); exit; } |
Se a conexão falhar, será disparada uma exceção, que será, posteriormente, pega no seu bloco catch correspondente. Nesse bloco, devemos colocar o nome da classe de exceção utilizada e criar uma variável, a qual será uma instância da exceção.
Para obter mais informações sobre exceções, veja o link abaixo:
http://www.php.net/manual/pt_BR/language.exceptions.php
Colaboraram neste artigo:
Anderson Mello
Beraldo
Fabyo
Latest posts by Roberto Beraldo (see all)
- Não Tenha Preguiça de Ler! - 25/04/2016
- Como Atualizar Scripts PHP de MySQL Para MySQLi - 29/10/2015
- Como usar PDO com banco de dados MySQL - 10/09/2015