|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[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. PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Fri Oct 24 03:00:02 2025 UTC |
> #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?