php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #49316 "Parse Error" not a meaningful/helpful error message
Submitted: 2009-08-21 06:38 UTC Modified: 2009-08-21 11:19 UTC
From: mwease at tx dot rr dot com Assigned:
Status: Not a bug Package: *General Issues
PHP Version: 5.3.0 OS: *
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: mwease at tx dot rr dot com
New email:
PHP Version: OS:

 

 [2009-08-21 06:38 UTC] mwease at tx dot rr dot com
Description:
------------
deficiency: an error message saying "parse error" on a given line is ridiculously insufficient.  the interpreter knows that there is a problem and MUCH more precisely what the problem is. in some instances, stating that something is missing or "expected" is helpful, but it is not believable to me that the real problem cannot be identified so that the "programmer" can understand what needs to be done to fix the error.  It's crazy to require the programmer to "parse" the "bad" line of code manually/humanly to figure out what the problem is when software (this interpreter) already knows there is a problem, what it is, and has identified it.  at LEAST provide a postion within the line, saying something at LEAST like "Expecting something else".

in addition, presuming that some unrecognizable "word" that is, in my case, actually a variable lacking the "$" in front and just replacing it with "NULL" and moving on is NOT helpful.  it's almost indifferent to the suffering! the interpreter should at LEAST say something about it!!

bottom line: DON'T JUST TELL ME THAT THERE IS A PROBLEM ON A PARTICULAR LINE, TELL ME WHAT THE PROBLEM IS EVERY TIME AND DO NOT ASSUME ANYTHING!!!!


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-08-21 08:37 UTC] sjoerd-php at linuxonly dot nl
Thank you for your bug report.

Providing a position within the line may be possible, but may also confuse things further. Consider the following example:

1 <?php
2 echo strlen('a')
3 echo strlen('a')
4 ?>

PHP thinks the error is on line 3 and says unexpected T_ECHO. The error is actually on line 2, a missing semicolon. PHP could propose things that are expected, but there are so many things possible that this is not helpful.

As shown, the linenumber is more of an indication than the real position. Providing the character on the line would not make much sense, since PHP does not know for sure that the error is exactly there. I agree that in some cases it can be helpful.

You describe an example where you forgot the $ for a variable. Like this:

<?php
echo foo;
?>

PHP assumes foo is a constant and it gives a notice about this:
PHP Notice:  Use of undefined constant foo - assumed 'foo' in /data/home/sjoerd/public_html/svnreps/test/a.php on line 2

If you don't see it, you probably have disabled notices. Enable them with error_reporting.
 [2009-08-21 11:19 UTC] jani@php.net
Just check from phpinfo() that your error_reporting is set properly. There's no bug to fix here.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Oct 15 02:01:27 2024 UTC