I have PHP set up for E_ALL, so usually receive notice/warning/error info in form:
Notice: Undefined variable: var in path\to\my\file on line 1
Now this has suddenly changed: my application is kicking them out in format
Noticepath\to\my\file1
i.e. no formatting, no description of the notice, just error-class, file-path and line number concatenated together
As far as I can tell nothing has changed with settings etc
If I do a simple test script the correct verbose format is still being produced
e.g.
echo $var;
where var is undefined
It just started happening this morning on an application that I am currently working on, which was not having this problem earlier, where as far as I can see nothing changed that should impact this
I haven't been able to find any remotely similar problems raised previously here or anywhere else so any suggestions would be much appreciated
OK: Fixed it. Thanks for help guys
Simple error - it was just the unexpected outcome in terms of impact on error reporting that threw me.
FYI: I had a variable called '$direct'; I missed the '$' in an if statement, and it looks like 'direct' in that context is meaningful
Related
Notice: Use of undefined constant test - assumed 'test'.
I am not sure where this error came from. I am using the Widget Logic Plugin and is fully updated, but I can't seem to find where this issue is. Has anyone had this issue and know how to resolve it?
The most likely answer is that you have missed a $ on a variable called $test and used test in your code somewhere.
This is hard to verify without your code, but the error message you are referring to is what generally happens when a variable is written without the $ at the start - PHP tries to assume it is a constant of the same name.
The second option is that there is an array index 'test' with the missing quotes, i.e. $array[test] instead of $array['test'].
Edit: If you are not writing any code yourself, and using only using plug-ins, you might want to do two things:
See if you can find the error in their code (search for a variable called test without a $ in front of it
Raise a bug on their site, so that they can update it
While my site was working without any problem I suddenly started to have a really high CPU usage on my server so I started to check the code more carefully and enabled E_ALL error reporting.
Then I found out I had a great many of this "notices":
Notice: Undefined index: userID in /var/www/vhosts/mydomain.com/httpdocs/header.php on line 8
Most or them refer to unset cookies, for example this:
$uid = $_COOKIE['userID'];
If the user is unlogged I get a notice right there, and every time I use $uid.
What I want to know if this: Are this notices harmless or can they really cause any problems in my site? (Speed issues, errors etc.)
It is a notice only, try this code:
$uid = isset($_COOKIE['userID']) ? $_COOKIE['userID'] : 0;
It is not hamless (depending on the point of view), and you can disable this with error reporting functions, otherwise, the correct way is verify if index exists isset($_COOKIE['userID']) and if not, define a default value (null for instance)
$var = isset($foo) ? $foo : 'default';
You need to verify if variable exists, if you don't known it exists or not.
$var = 'foo'
if($var == 'foo') { // I known $var is defined, because I have defined it.
[..]
}
/**
* Above, I don't known if user go to mywebsite.com/index.php or
* mywebsite.com/index.php?foo=bar, so, I need to verify if index is defined
*/
if(isset($_GET['foo']) && $_GET['foo'] == 'bar') {
[...]
}
Those notices will cause a little bit of a speed problem, because raising a notice costs some extra effort.
The main problem though is that this is a serious error. You are trying to work with something that doesn't exist. This may or may not lead to Bad Things Happening, but it means your program is not correct. Since you should always develop with error reporting on full power to see and solve actual problems, notices about undefined indexes or undefined variables are serious and need to be solved. Anything that PHP complains about is serious and needs to be solved. See The Definitive Guide To PHP's isset And empty.
Notices are in general harmless, yet they may indicate a poor application design. In general it is always a good idea to utilize available PHP tools (i.e isset($someVar)) to make sure that your business logic is taking proper care of variable initialization. When you see no such notices with E_ALL error reporting setting, it's always better.
The Notice warning is in the first point of view harmless, but you should keep in mind, that the programming is not right and it might be causes errors on following lines.
In your example it es better to use
$uid = isset($_COOKIE['userID'])?$_COOKIE['userID']:0;
So you can be sure, that $uid always has a value and when the value greater then 0 you have a falid userId ...
As a developer, I work with E_NOTICE turned on. Recently though, I was asked why E_NOTICE errors should be fixed. The only reason that I could come up with was that it is best practice to correct those problems.
Does anyone else have any reasons to justify the extra time/cost spent to correct these problems?
More specifically, why should a manager spend the money to have these fixed if the code already works?
SUMMARY
The PHP Runtime Configuration Docs give you some idea why:
Enabling E_NOTICE during development has some benefits.
For debugging purposes: NOTICE messages will warn you about possible bugs in your code. For example, use of unassigned values is warned. It is extremely useful to find typos and to save time for debugging.
NOTICE messages will warn you about bad style. For example, $arr[item] is better to be written as $arr['item'] since PHP tries to treat "item" as constant. If it is not a constant, PHP assumes it is a string index for the array.
Here's a more detailed explanation of each...
1. TO DETECT TYPOS
The main cause of E_NOTICE errors is typos.
Example - notice.php
<?php
$username = 'joe'; // in real life this would be from $_SESSION
// and then much further down in the code...
if ($usernmae) { // typo, $usernmae expands to null
echo "Logged in";
}
else {
echo "Please log in...";
}
?>
Output without E_NOTICE
Please log in...
Wrong! You didn't mean that!
Output with E_NOTICE
Notice: Undefined variable: usernmae in /home/user/notice.php on line 3
Please log in...
In PHP, a variable that doesn't exist will return null rather than causing an error, and that could cause code to behave differently than expected, so it's best to heed E_NOTICE warnings.
2. TO DETECT AMBIGUOUS ARRAY INDEXES
It also warns you about array indexes that might change on you, e.g.
Example - code looks like this today
<?php
$arr = array();
$arr['username'] = 'fred';
// then further down
echo $arr[username];
?>
Output without E_NOTICE
fred
Example - tomorrow you include a library
<?php
// tomorrow someone adds this
include_once('somelib.php');
$arr = array();
$arr['username'] = 'fred';
// then further down
echo $arr[username];
?>
and the library does something like this:
<?php
define("username", "Mary");
?>
New output
Empty, because now it expands to:
echo $arr["Mary"];
and there is no key Mary in $arr.
Output with E_NOTICE
If only the programmer had E_NOTICE on, PHP would have printed an error message:
Notice: Use of undefined constant username - assumed 'username' in /home/user/example2.php on line 8
fred
3. THE BEST REASON
If you don't fix all the E_NOTICE errors that you think aren't errors, you will probably grow complacent, and start ignoring the messages, and then one day when a real error happens, you won't notice it.
Because an E_NOTICE indicates an error.
PHP is just too forgiving to call it that.
For example, accessing an undefined variable produces an E_NOTICE.
If this happens often, for example because you're not initializing your variables correctly, and your app is throwing notices all over the place, how are you going to tell the difference between a "variable that works just fine uninitialized" and times when you have really fat-fingered a variable name?
This may trigger a notice but will work as intended, so you ignore the notice:
if ($_GET['foo']) ...
This, on the other hand, will waste half your day while you ignore the notice and are trying to figure out why your "bar() function doesn't work":
$foo = bar();
if ($too) ...
If you don't "fix" the former case, where the variable may legitimately not exist, you can't meaningfully use notices to catch the typo in the second case.
Notices are there to help you debug your app. If you ignore them, you're only making your own life more difficult.
This kind of errors are good practice to fix, as they are what we call "code smell" they hint of another problem (like mistyped variable names or usage of undefined variables/wrong usage of methods) , or they will probably cause bugs down the road when you reflector/expand the system.
Of course, what I said here is not true 100% of the cases.
Ben I think this is an excellent question. True, it is a good practice to follow to attempt to correct any and all errors, even non-fatal ones, unless doing to would impede the designed (and thus desired) functionality of the system. Moreover, any level of error indicates that either:
a) There is something wrong with your code, or,
b) You have written code that is deprecated, or have written code that is otherwise unstable and thus prone to side effects.
Therefore, I believe that if the timeline and budget of a project allows you to do so, you should always strive to correct as many errors as possible, even if they are minor in terms of their impact on the final product.
Of course, there is a certain level of risk acceptance involved in cost-benefit analysis, so it may very well be the case that the managers overseeing the outcome of the project are willing to hedge the potential future cost of fixing a known issue against the present time and cost savings associate with not fixing an error. The math basically works out the way you think it would: If the PV of the cost of fixing the error in the future is less than the money saved today by not fixing the error, then you should not fix it. On the other hand, if the PV of the cost of fixing the error in the future is greater than the money saved today by not fixing it, then you should fix it today.
That, really, is the justification for (or against) fixing an error today, regardless of the error level.
Often they're indicative of logic errors or typos. They'll help you spot situations where you've mistyped a variable name or are trying to use a variable before it's been set.
I've also seen arguments that it's more efficient to avoid errors
I have an old application witch pops up an error at a certain location. The error is about an wrong set variable. Only from the error it is not possible to find the location where the variable is set wrong. Now my idea is to use reflections to find the location.
Is it possible to use reflections to find the code position at which a variable gets a certain value?
The idea: I have the name and the value of the variable. Now if both are matching a certain event should be triggered and echo the actual parsed file and line number.
Every ideas that help are appreciated.
Thank you,
-lony
P.S.: Is it possible even if the application is not really object oriented and uses a lot of spaghetti code?
I would be you do a debug_backtrace at the point where the error occurs and try to exploit the stack trace to see where the variable is changed. The debug_backtrace would give you a list of file included after it should be fairly easy to filter a list of line with a global search (i.e. grep)
var_dump(debug_backtrace())
if (variable == value) {
echo "variable equals value, line #whatever"+"<br/>";
}
Just place these at various points in code and see which ones display. Manually enter line numbers.
I found a solution to one of my problems.
The function debug_print_backtrace helped me finally debugging my spaghetti code. I found it by reading this post.
-Cheers
Python's convention is that variables are created by first assignment, and trying to read their value before one has been assigned raises an exception. PHP by contrast implicitly creates a variable when it is read, with a null value. This means it is easy to do this in PHP:
function mymodule_important_calculation() {
$result = /* ... long and complex calculation ... */;
return $resukt;
}
This function always returns null, and if null is a valid value for the functuion then the bug might go undetected for some time. The Python equivalent would complain that the variable resukt is being used before it is assigned.
So... is there a way to configure PHP to be stricter with variable assignments?
PHP doesn't do much forward checking of things at parse time.
The best you can do is crank up the warning level to report your mistakes, but by the time you get an E_NOTICE, its too late, and its not possible to force E_NOTICES to occur in advance yet.
A lot of people are toting the "error_reporting E_STRICT" flag, but its still retroactive warning, and won't protect you from bad code mistakes like you posted.
This gem turned up on the php-dev mailing-list this week and I think its just the tool you want. Its more a lint-checker, but it adds scope to the current lint checking PHP does.
PHP-Initialized Google Project
There's the hope that with a bit of attention we can get this behaviour implemented in PHP itself. So put your 2-cents on the PHP mailing list / bug system / feature requests and see if we can encourage its integration.
There is no way to make it fail as far as I know, but with E_NOTICE in error_reporting settings you can make it throw a warning (well, a notice :-) But still a string you can search for ).
Check out error reporting, http://php.net/manual/en/function.error-reporting.php
What you want is probably E_STRICT. Just bare in mind that PHP has no namespaces, and error reporting becomes global. Kind of sucks to be you if you use a 3rd party library from developers that did not have error reporting switched on.
I'm pretty sure that it generates an error if the variable wasn't previously declared. If your installation isn't showing such errors, check the error_reporting() level in your php.ini file.
You can try to play with the error reporting level as indicated here: http://us3.php.net/error_reporting but I'm not sure it mention the usage of non initiated variable, even with E_STRICT.
There is something similar : in PHP you can change the error reporting level. It's a best practice to set it to maximum in a dev environnement. To do so :
Add in your PHP.ini:
error_reporting = E_ALL
Or you can just add this at the top of the file your are working on :
error_reporting(E_ALL);
This won't prevent your code from running but the lack of variable assignments will display a very clear error message in your browser.
If you use the "Analyze Code" on files, or your project in Zend Studio it will warn you about any uninitialized variables (this actually helped find a ton of misspelled variables lurking in seldom used portions of the code just waiting to cause very difficult to detect errors). Perhaps someone could add that functionality in the PHP lint function (php -l), which currently only checks for syntax errors.