php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #70283 Misleading error message when attempting to instantiate a reserved class name
Submitted: 2015-08-17 16:55 UTC Modified: 2016-03-28 08:34 UTC
Votes:3
Avg. Score:3.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:1 (50.0%)
From: bugs dot php dot net at majkl578 dot cz Assigned:
Status: Suspended Package: Scripting Engine problem
PHP Version: 7.0Git-2015-08-17 (Git) OS: Linux
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: bugs dot php dot net at majkl578 dot cz
New email:
PHP Version: OS:

 

 [2015-08-17 16:55 UTC] bugs dot php dot net at majkl578 dot cz
Description:
------------
When trying to instantiate a reserved class name (e.g. string/int/float/resource), the message should probably mention that the name is reserved, not that "class ____ not found".

Test script:
---------------
<?php
new string;

Expected result:
----------------
Somethig like:
Fatal error: Uncaught Error: Could not instantiate 'string', the name is reserved

Actual result:
--------------
Fatal error: Uncaught Error: Class 'string' not found

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-09-16 13:42 UTC] jonathan dot massuchetti at gmail dot com
PHP 5 behavior when trying to instantiate a reserved word, such as "new return", "new class" or so, is a parse error :

Parse Error: syntax error, unexpected 'class' (T_CLASS)

So IMHO we should :

A) stick to that behavior and trigger a parse error
B) create a new error message for all reserved word usage attempt.

I vote A.
 [2015-12-08 22:11 UTC] yohgaki@php.net
-Summary: Misleading error message when attempting to instantiate a reserved class name +Summary: Manual does not mention new reserved keywords (string/etc) -Package: Scripting Engine problem +Package: Documentation problem
 [2015-12-08 22:11 UTC] yohgaki@php.net
It seems ok to me raising E_ERROR for non defined classes and raising E_ERROR for non language instruction keywords. (Strictly speaking, "string" class is not parse error, but soft limitation)

http://php.net/manual/en/reserved.keywords.php
does not mention new "string"/etc keywords. I'll make this report as Documentation problem.

[yohgaki@dev PHP-7.0]$ ./php-bin 
<?php
class string{}
?>

Fatal error: Cannot use 'string' as class name as it is reserved in - on line 2
[yohgaki@dev PHP-7.0]$ ./php-bin 
<?php
class int{}
?>


Fatal error: Cannot use 'int' as class name as it is reserved in - on line 2




[yohgaki@dev PHP-7.0]$ php -v
PHP 5.6.15 (cli) (built: Oct 29 2015 15:24:09) 
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies
    with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2015, by Zend Technologies
[yohgaki@dev PHP-7.0]$ php
<?php
class while{}
?>


PHP Parse error:  syntax error, unexpected 'while' (T_WHILE), expecting identifier (T_STRING) in - on line 2
 [2015-12-17 08:43 UTC] cmb@php.net
-Summary: Manual does not mention new reserved keywords (string/etc) +Summary: Misleading error message when attempting to instantiate a reserved class name -Package: Documentation problem +Package: Scripting Engine problem
 [2015-12-17 08:43 UTC] cmb@php.net
yohgaki wrote:
> http://php.net/manual/en/reserved.keywords.php
> does not mention new "string"/etc keywords. I'll make this
> report as Documentation problem.

Type names (`string` etc.) are not proper keywords, but rather
reserved names and already listed as such[1]. Therefore this issue
is not a documentation issue.

jonathan dot massuchetti at gmail dot com wrote:
> A) stick to that behavior and trigger a parse error

Please note the difference between proper keywords and reserved
words. The former will trigger parse errord when used in
(syntactically) invalid contexts, but, IMHO rightly so, not the
latter. For instance, it's possible to use `string` as name of a
user defined function[2].

[1] <http://php.net/manual/en/reserved.other-reserved-words.php>
[2] <https://3v4l.org/IR9Hq>
 [2016-03-28 08:34 UTC] krakjoe@php.net
-Status: Open +Status: Suspended -Type: Bug +Type: Feature/Change Request
 [2016-03-28 08:34 UTC] krakjoe@php.net
This is a feature request, not a bug, or a documentation problem.

Making something that results in an exception (like new string;), result in a fatal error (which is what compiler errors are) has BC implications.

You might suggest that we don't raise a compiler error, and wait until runtime to raise an exception: In that case, why do some uses of reserved names result in errors and others in exceptions ?

These kinds of issues cannot be resolved by discussion on this issue tracker.

Please see: https://wiki.php.net/rfc/howto
 [2016-03-29 08:50 UTC] iletaitunefoisfenghuang at gmail dot com
@krakjoe : I understand your point. The author of the "bug" ask for a message change, not a error type change. 

The throwable Error for a class not found would need to check if the class requested is a reserved name, to update the error message.

While it is a feature request, it doesn't deserve an RFC.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 11:01:29 2024 UTC