Qual é a configuração de error_reporting() recomendada para desenvolvimento?E quanto a E_STRICT?

Question

Normalmente eu uso E_ALL para ver qualquer coisa que o PHP possa dizer sobre meu código para tentar melhorá-lo.

Acabei de notar uma constante de erro E_STRICT, mas nunca usei ou ouvi falar sobre isso, essa é uma boa configuração para uso no desenvolvimento?O manual diz:

Avisos em tempo de execução.Habilite para que o PHP sugira alterações em seu código que garantirão a melhor interoperabilidade e compatibilidade futura de seu código.

Então, estou me perguntando se estou usando o melhor error_reporting nível com E_ALL ou isso junto com E_STRICT seja o melhor?Ou há alguma outra combinação que ainda não aprendi?

Answer 1

No PHP 5, as coisas cobertas por E_STRICT não estão cobertas pelo E_ALL, portanto, para obter o máximo de informações, você precisa combiná-los:

 error_reporting(E_ALL | E_STRICT);

No PHP 5.4, E_STRICT será incluído em E_ALL, então você pode usar apenas E_ALL.

Você também pode usar

error_reporting(-1);

que sempre permitirá todos erros.O que é mais semanticamente correto como:

error_reporting(~0);

Answer 2

Use o seguinte no php.ini:

error_reporting = E_ALL | E_STRICT

Além disso, você deve instalar Xdebug, ele pode destacar seus erros ao cegar cores brilhantes e imprimir informações detalhadas úteis.

Nunca deixe nenhum erro ou aviso em seu código, mesmo que seja inofensivo.

Answer 3

Na minha opinião, quanto mais alto você definir o nível de relatório de erros na fase de desenvolvimento, melhor.

Em um ambiente ao vivo, você deseja um conjunto ligeiramente (mas apenas ligeiramente) reduzido, mas deseja que eles sejam registrados em algum lugar onde não possam ser vistos pelo usuário (eu prefiro syslog).

http://php.net/error_reporting

E_ALL | E_STRICT para desenvolvimento com PHP antes de 5.2.0.

5.2 apresenta E_RECOVERABLE_ERROR e 5.3 apresenta E_DEPRECATED e E_USER_DEPRECATED.Você provavelmente desejará ativá-los se estiver executando uma dessas versões.

Se você quisesse usar números mágicos, você poderia simplesmente definir o error_reporting valor para algum valor bastante alto de 2^n-1 - dizer, 16777215, e isso realmente ativaria todos os bits entre 1..n.Mas não acho que usar números mágicos seja uma boa ideia...

Na minha opinião, o PHP deixou a bola cair um pouco ao ter E_ALL realmente não é tudo.Mas aparentemente isso será corrigido no PHP 6...

Answer 4

Nas versões mais recentes do PHP, E_ALL inclui mais classes de erros.Desde o PHP 5.3, E_ALL inclui tudo exceto E_ESTRITO.No PHP 6, supostamente incluirá até isso.Esta é uma boa dica:é melhor ver mais mensagens de erro do que menos.

O que está incluído em E_ALL está documentado no Constantes predefinidas em PHP página do manual on-line.

Pessoalmente, acho que não importa muito se você usa E_STRICT.Certamente não irá prejudicá-lo, especialmente porque pode impedi-lo de escrever scripts que têm uma pequena chance de serem quebrados em versões futuras do PHP.Por outro lado, em alguns casos, mensagens rígidas podem ser muito barulhentas, especialmente se você estiver com pressa.Sugiro que você o ative por padrão e desligue-o quando ficar irritante.

Answer 5

Você pode usar error_reporting = -1
Sempre consistirá em todos os bits (mesmo que não estejam em E_ALL)

Answer 6

Dependendo dos seus planos de suporte de longo prazo para este código, a depuração com E_STRICT enabled pode ajudar seu código a continuar funcionando em um futuro distante, mas provavelmente é um exagero para o uso diário.Há duas coisas importantes sobre E_STRICT para ter em mente:

1. De acordo com o manual, maioria E_STRICT erros são gerados em tempo de compilação, não em tempo de execução.Se você estiver aumentando o nível de erro para E_ALL dentro do seu código (e não via php.ini), talvez você nunca veja E_STRICT erros de qualquer maneira.
2. E_STRICT está contido dentro E_ALL no PHP 6, mas não no PHP 5.Se você atualizar seu servidor para PHP6 e tiver E_ALL configurado conforme descrito no item 1 acima, você começará a ver E_STRICT erros sem exigir quaisquer alterações adicionais de sua parte.

Answer 7

Não falando estritamente de error_reporting, eu fortemente sugiro usar qualquer IDE que mostre automaticamente erros de análise e falhas comuns (por exemplo, atribuição em condições).

Zend Studio for Eclipse tem esse recurso habilitado por padrão, e desde que comecei a usá-lo, ele tem me ajudado bastante em detectar erros antes que eles ocorram.

Por exemplo, eu tinha esse trecho de código onde estava armazenando alguns dados em cache no $GLOBALS variável, mas eu inadvertidamente escrevi $_GLOBALS em vez de.Os dados nunca foram armazenados em cache e eu nunca saberia se Zend não me dissesse:"Ei, isso $_GLOBALS coisa aparece apenas uma vez, isso pode ser um erro".

Answer 8

ini_set("display_errors","2");ERROR_REPORTING(E_ALL);