php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #47783 Error messages often don't make sense.
Submitted: 2009-03-26 03:23 UTC Modified: 2015-06-22 08:19 UTC
Votes:5
Avg. Score:4.8 ± 0.4
Reproduced:5 of 5 (100.0%)
Same Version:2 (40.0%)
Same OS:2 (40.0%)
From: nairbv at yahoo dot com Assigned: kalle (profile)
Status: Closed Package: *General Issues
PHP Version: 5.2.9 OS:
Private report: No CVE-ID: None
 [2009-03-26 03:23 UTC] nairbv at yahoo dot com
Description:
------------
Error messages often don't make sense.  for example:

Catchable fatal error:  Argument 1 passed to my_function() must be an instance of string, string given

I'd comment on this bug:
http://bugs.php.net/bug.php?id=42118

But this reporting system doesn't permit commenting on existing bugs.

The bug is NOT bogus.  The error message IS non-sense.  It's fine if you're not going to support primitive type hinting, but the message should say something to that effect.

Also the error is NOT "catchable."  See bug:
http://bugs.php.net/bug.php?id=41948

Again, I'd comment on that bug, but I can't comment on existing bugs.

If the error can only be handled by setting an error handler, and not caught with a "catch" block, the error message should say "RECOVERABLE error" or "handleable" or something to that effect, not "catchable error."

Other bad error messages include:
"Can't use method return value in write context"
see bug: http://bugs.php.net/bug.php?id=44565

"write context" is meaningless to the programmer.

On that bug, the reporter commented that the message is not helpful.  Why was the bug closed instead of fixing the error message??



Reproduce code:
---------------
for the first error message:
function my_function(string $str) {}
bar('');

for the second error message:
empty($foo->getValue());

or also the code in bug #44565.



Expected result:
----------------
error messages that help the programmer.  

for the "catchable" error regarding type hinting:
Either something like: 
"Recoverable fatal error: reference to undefined class 'string' on line [line of type hint]" or:
"Recoverable fatal error:  Argument 1 passed to my_function() must be an instance of class string, primitive string given."

For the empty($foo->getbar());"write context" message:
It should probably say something like "cannot use method return value when calling internal language constructs" ... or something like that.

For the "write context" message referenced in bug 44565:
it should give the '"call-time pass-by-reference" is deprecated when you use & in foo(&$a);' like the documentation (http://docs.php.net/manual/en/language.references.pass.php) says it will.


Actual result:
--------------
Useless (and sometimes amusing) error messages like "must be an instance of string, string given" or the "write context" message which as far as I know is in reference to some implementation detail internal to php.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-06-22 08:19 UTC] kalle@php.net
-Status: Open +Status: Closed -Package: Feature/Change Request +Package: *General Issues -Assigned To: +Assigned To: kalle
 [2015-06-22 08:19 UTC] kalle@php.net
Let me clarify these a little for you:

#42118 - There was no type hinting at the time, in fact it is just being introduced now with PHP 7.
#41948 - E_RECOVERABLE_ERROR is an error, not an exception, but it could have been caught with a catch block if ErrorException + set_error_handler() was used.
#44565 - The example not working was because &$obj->method() means $obj->method() returns a string, that is then written to a temp string with, but you cannot reference a temp string so that is why you cannot write to that context. If the method return value was intended to have a return value that was going to be a refence, then the method signature should be declared as such and the usage context have been different.

As for the issue you stated: "Catchable fatal error:  Argument 1 passed to my_function() must be an instance of string, string given" does not make sense.  While I understand that it may not be crystal clear for all, then keep in mind that PHP supports objects and primitive types, objects are "instances" and primitives are well, just primitives.

But there is good news for you, as of PHP7 we have scalar type declarations (and even return type hinting).

We are always open for PR's on Github if you feel like you can improve the error message.
 [2015-06-22 12:08 UTC] nairbv at yahoo dot com
> #42118 - There was no type hinting at the time, in fact it is just being introduced now with PHP 7.

HUH?

brian@desktop ~ $ php -r 'class myobj {}; class myobj2{}; function foo(myobj $foo) {}; foo(new myobj);foo(new myobj2);'
PHP Catchable fatal error:  Argument 1 passed to foo() must be an instance of myobj, instance of myobj2 given, called in Command line code on line 1 and defined in Command line code on line 1
brian@desktop ~ $ php --version
PHP 5.6.7-1 (cli) (built: Mar 24 2015 12:30:15) 

Notice there was no error when pasing new myobj, only new myobj2.

There is type hinting in PHP for classes and has been for quite some time.  I haven't written PHP in years and there was type hinting when I was using it.  The reason for the error message is that 'string' is considered a primitive and type hinting only works for classes.  If there was no type hinting as you claim, there should have been a completely different error message, probably a parse error.

> #41948 - E_RECOVERABLE_ERROR is an error, not an exception, but it could have been caught with a catch block if ErrorException + set_error_handler() was used.

I don't think that's actually true.  You could handle it with an error handler, but not a "catch block."  Even if you were correct, SAY that in the error message.  Maybe it should be called "HANDLEABLE_FATAL_ERROR."

etc etc etc.

All of your comments, I'm not claiming these errors are invalid (even though some of your responses are factually incorrect).  I'm pointing out that the error MESSAGES are not helpful to the programmer.  Explaining why the error messages are valid is not a counter argument to their lack of clarity of expressiveness.

> We are always open for PR's on Github if you feel like you can improve the error message.

Claiming I can fix these problems myself doesn't mean the bug report is invalid.  Even if I or someone else were to submit a pull request, shouldn't they be submitting it against some open bug?  What is your reason  closing this ticket?
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 19 23:01:28 2024 UTC