[RESOLVED] error messages problem

xentia

Hi all,

i've just install a new php 5.2.8 on apache and when perform a initial testing a follow problem was occur:

php code with error on it:

<?php

echo ; 'Error! Error!';

and result in browser:

Parse error: parse error in C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\xentia\002.php on line 3

instead a result generated from our old php4 server

Parse error: syntax error, unexpected ';' in C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\xentia\002.php on line 3

well, showing errors is enabled and error reporting is set to E_ALL in php.ini, but still that short form of error message from php 5.2.8 engine is confuse. Without this hints is much difficult for debugging

Any ideas? Thank's in advance

laserlight

hmm... my local PHP 5.2.6 installation shows the more descriptive error message.

bradgrafelman

I'm running PHP Version 5.2.8, Windows XP SP2, Apache 2.2, PHP integrated as an ISAPI module, and I get the less descriptive error message (the first one) as well.

EDIT: Just upgraded to version 5.2.9-2 and I still get the less descriptive error message. I couldn't easily find a copy of 5.2.7 (it was removed do a security bug), but it appears that between version 5.2.6 and 5.2.8, the PHP parser changed how it reported parsing errors in some way.

Same for 5.2.10-dev, 5.3.0RC3-dev, and 6.0.0-dev.

scrupul0us

well

<?php

echo ; 'Error! Error!';

?>

is wrong... you have a ';' between the echo and the 'Error! Error!';

youll find this works

echo 'Error! Error!';

bradgrafelman

Right, we agree that it's wrong - it's the fact that the error message has become less descriptive that we're discussing. :p

scrupul0us

well everything makes sense when you point out the obvious brad 😃

xentia

Excuse me if my explain was not so clear 🙂 Whatever, fact is fact, PHP 5.2.8 generate a tiny error description. I've also try at 5.3.0RC3-dev - same result. On 5.2.6 and 5.2.7 the error message was on wide variant - mean more descreptive text appear. Very, very interesting. Seems that parser just threat that kind of error on different way. Also - on Apache error log file - text is in same format:

[Tue May 19 21:18:27 2009] [error] [client 127.0.0.1] PHP Parse error: parse error in C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\xentia\002.php on line 3

bradgrafelman

@: On a hunch, I search and finally opened a new ticket over at bugs.php.net (link to ticket). I'm still awaiting more feedback from a developer, but it at least wasn't shot down/marked bogus after the first response, so it looks as though there was indeed a change in the Windows builds that now produces less verbose error messages.

scrupul0us

just out of curiosity, what value does it hold to know the reason for the difference? Is it something that could cause the handling of errors to be off in custom error handlers or...

bradgrafelman

@: In this specific example it probably does seem quite trivial. However, I've come to speak the language of PHP errors quite well - they can certainly be very helpful in determining the cause of an error before you even look at the code. I would be very disappointed if PHP developers were intentionally shortening error messages by removing helpful details such as what kind of parse error the parser encountered.

xentia

@: i've just read responses from php.net ticket that you open (thanks 🙂 - and also can confirm that on *nix error messages is in order - mean they are in full description format. My try was on Ubuntu and Apache and 5.2.9 source downloaded from php.net
Hope that in 5.0 release this stuff will be revised

bradgrafelman

I don't know if xentia, et al. are still watching this thread, but I wanted to update it (and mark it resolved) since I just got an e-mail reply today from one of the PHP developers.

I've now closed the bug ticket over at php.net, as it seems like they've fixed the parse error description on Windows builds as of at least the Windows snapshot build created on "2010-Feb-24 15:38:53". It may have been fixed in versions prior to that build, though, but I haven't looked at this issue in quite some time.