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 ...
Related
So.. I'm still confused by this, when creating an array with $array = array(); and then manually setting variables like:
<?php
$array[] = 1;
$array['type'] = 2;
$array['number'] = 3;
I know, this is OK for PHP to do, but then when I echo something like $array['none'] it won't show a E_NOTICE for undefined variables.
Can someone explain me, why?
It will. If you have turned on error reporting, it should display a warning similar to the one below:
Notice: Undefined index: none in /path/to/script.php line X.
To check, try the following:
<?php
ini_set('display_errors',1);
error_reporting(E_ALL);
$array = array();
echo $array['none'];
And, if you want to actually make sure they exist before trying to use them in your code, use isset():
if(isset($array['none'])) {
// do stuff ...
}
See it live!
All this is explained on the config doc page, too:
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.
It's quite simple: When you access a key that doesn't exist, and assign it a new value, PHP will create that key, and add it to the list (or array). But when you try to access a non-existing key, and attempt to echo it's value, PHP won't crash, but it'll let you know that your code contains a possible bug:
$arr = array('foo' => 'bar');
echo $arr['fo'];
This issues a notice because my code may contain a typo. I may expect the key fo to exist, while clearly it doesn't, so I need to work on my code some more.
Another reason why this notice is issued is because lookups for non existing properties/keys are "slow". In order for PHP to know for a fact that the key doesn't exist, the entire array has to be scanned. That, too, is not ideal, though inevitable at times. If you have code that issues tons of E_NOTICE's, chances are that some simple if's, like:
if (!isset($arr['fo']))
{
$arr['fo'] = '';
}
echo $arr['fo'];
Will, though adding more code, effectively speed up your code. Not in the least because issueing notices isn't free (it's not that expensive, but not free either).
Other benefits:
Notices also let you know when you forgot to quote array keys, for example
echo $arr[foo];
echo $arr['foo'];
Initially, both will echo bar, but let's add 1 line of code to this:
define('foo', 'bar');
echo $arr[foo];
echo $arr['foo'];
This won't, because foo is now a constant, so $arr[foo] amounts to $arr['bar'];, which is an undefined index. Turning off notices, will just echo the string representation of NULL, which is an empty string.
Basically, notices help you. Use them, listen to them, and fix them. If your site is broken, fix it. If you get into the habbit of ignoring these notices, you'll probably set your ini files to a more "forgiving" setting, and grow lazy.
As time progresses, your code will become ever more messy/smelly, until such time you actually have a difficult to trace bug. You'll decide to turn your error reporting to E_STRICT | E_ALL, and won't be able to see the actual notice/warning that points out where your bug actually is, because your screen will be cluttered with E_NOTICE undefined index/variable...
So I'm working on cleanup of a horrible codebase, and I'm slowly moving to full error reporting.
It's an arduous process, with hundreds of notices along the lines of:
Notice: Undefined index: incoming in /path/to/code/somescript.php on line 18
due to uses of variables assuming undefined variables will just process as false, like:
if($_SESSION['incoming']){
// do something
}
The goal is to be able to know when a incorrectly undefined variable introduced, the ability to use strict error/notice checking, as the first stage in a refactoring process that -will- eventually include rewriting of the spots of code that rely on standard input arrays in this way. There are two ways that I know of to replace a variable that may or may not be defined
in a way that suppresses notices if it isn't yet defined.
It is rather clean to just replace instances of a variable like $_REQUEST['incoming'] that are only looking for truthy values with
#$_REQUEST['incoming'].
It is quite dirty to replace instances of a variable like $_REQUEST['incoming'] with the "standard" test, which is
(isset($_REQUEST['incoming'])? $_REQUEST['incoming'] : null)
And you're adding a ternary/inline if, which is problematic because you can actually nest parens differently in complex code and totaly change the behavior.
So.... ...is there any unacceptable aspect to use of the # error suppression symbol compared to using (isset($something)? $something : null) ?
Edit: To be as clear as possible, I'm not comparing "rewriting the code to be good" to "#", that's a stage later in this process due to the added complexity of real refactoring. I'm only comparing the two ways (there may be others) that I know of to replace $undefined_variable with a non-notice-throwing version, for now.
Another option, which seems to work well with lame code that uses "superglobals" all over the place, is to wrap the globals in dedicated array objects, with more or less sensible [] behaviour:
class _myArray implements ArrayAccess, Countable, IteratorAggregate
{
function __construct($a) {
$this->a = $a;
}
// do your SPL homework here: offsetExists, offsetSet etc
function offsetGet($k) {
return isset($this->a[$k]) ? $this->a[$k] : null;
// and maybe log it or whatever
}
}
and then
$_REQUEST = new _myArray($_REQUEST);
This way you get back control over "$REQUEST" and friends, and can watch how the rest of code uses them.
You need to decide on your own if you rate the # usage acceptable or not. This is hard to rate from a third party, as one needs to know the code for that.
However, it already looks like that you don't want any error suppression to have the code more accessible for you as the programmer who needs to work with it.
You can create a specification of it in the re-factoring of the code-base you're referring to and then apply it to the code-base.
It's your decision, use the language as a tool.
You can disable the error suppression operator as well by using an own callback function for errors and warnings or by using the scream extension or via xdebug's xdebug.scream setting.
You answered you question yourself. It suppress error, does not debug it.
In my opinion you should be using the isset() method to check your variables properly.
Suppressing the error does not make it go away, it just stops it from being displayed because it essentially says "set error_reporting(0) for this line", and if I remember correctly it would be slower than checking isset() too.
And if you don't like the ternary operator then you should use the full if else statement.
It might make your code longer but it is more readable.
I would never suppress errors on a development server, but I would naturally suppress errors on a live server. If you're developing on a live server, well, you shouldn't. That means to me that the # symbol is always unacceptable. There is no reason to suppress an error in development. You should see all errors including notices.
# also slows things down a bit, but I'm not sure if isset() is faster or slower.
If it is a pain to you to write isset() so many times, I'd just write a function like
function request($arg, $default = null) {
return isset($_REQUEST[$arg]) ? trim($_REQUEST[$arg]) : $default;
}
And just use request('var') instead.
Most so-called "PHP programmers" do not understand the whole idea of assigning variables at all.
Just because of lack of any programming education or background.
Well, it isn't going a big deal with usual php script, coded with considerable efforts and consists of some HTML/Mysql spaghetti and very few variables.
Another matter is somewhat bigger code, when writing going to be relatively easy but debugging turns up a nightmare. And you are learn to value EVERY bloody error message as you come to understanding that error messages are your FRIENDS, not some irritating and disturbing things, which better to be gagged off.
So, upon this understanding you're learn to leave no intentional errors in your code.
And define all your variables as well.
And thus make error messages your friends, telling you that something gone wrong, lelping to hunt down some hard-spotting error which caused by uninitialized variable.
Another funny consequence of lack of education is that 9 out of 10 "PHP programmers" cannot distinguish error suppression from turning displaying errors off and use former in place of latter.
I've actually discovered another caveat of the # beyond the ones mentioned here that I'll have to consider, which is that when dealing with functions, or object method calls, the # could prevent an error even through the error kills the script, as per here:
http://us3.php.net/manual/en/language.operators.errorcontrol.php
Which is a pretty powerful argument of a thing to avoid in the rare situation where an attempt to suppress a variable notice suppressed a function undefined error instead (and perhaps that potential to spill over into more serious errors is another unvoiced reason that people dislike #?).
The following code generates a notice if $n is not set. Solving it requires an additional statement (isset($n)) or to "declare" the $n ($n=''). But what consequences does this notice have? The below code is a lot neater and lets say we turn error_reporing off in production no difference is visible frontend. Does something bad follows? Prestanda, readability etc? (sorry for the bad english)
if($n==1){
//do something
}
There is no "consequence" to notices, per sé, other than bad coding practices. You should be coding with error_reporting set to E_ALL on your development machines, so obviously the consequence there is a lot of notices...
I would argue that your code actually isn't neat, because you're testing a variable which doesn't get set previously.
A suggestion would be something like this:
<?php
if (!empty($n) && $n == 1)
{
//do something
}
empty checks for existence automatically (just like calling isset before it) but it also checks to make sure your value doesn't evaluate as false with values like false, 0, or '' (empty string).
A notice means that while your code will work as expected, it isn't written "like it should be". It's like the compiler telling you "I know what you mean here and I can do it, but you shouldn't rely on this. Please write it differently so I don't have to make assumptions".
Therefore a notice by itself doesn't mean that something bad happens most of the time. However, I wouldn't call anyone who accepts notices in their code a professional programmer because fixing the notices is a pretty simple task and not having any notices says that you understand the language's basics well. If someone can't or don't want to do even this much, it says something about them.
In your specific example, something like this should be done:
$n = null; // or some other appropriate initial value
// possibly change the value of $n here
if($n==1) {
//do something
}
Note that by writing the extra $n = null, you are not making the program any different as far as the compiler is concerned (it will end up doing that itself at the same time it gives out the notice anyway). But you are making it very different as far as someone reading the code is concerned: with this code they won't have a "WTF did this $n come from???" moment.
Normally in the production environments all error reporting which come strait from PHP libraries is turned off or parsed before showing to end user (it`s still logged).
There are no consequences in notice, it`s just notice to developer that something bad could happen in this place, in your example initializing the variable with value.
I encountered one function that handling "PHP Notice" can be beneficial.
The function is:
geoip_record_by_name()
This function return "false" and send "PHP Notice" on IP's that do not find in its database.
The standard is that IP's reserved for internal networks, or Localhost will not be found.
As a horrible practice this function treat this normal condition as bed coding. WRRRRR!!!
There is solution to filter local IP,s before sending to this function ( assuming that all other addresses are covered by geoip database).
I consider this geoip_record_by_name() as pest function that handling of "PHP Notice" is justified.
Discussion related to this pest function
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
Since i changed my error reporting level to error_reporting(E_ALL | E_STRICT); I am facing this error. I can obviate from this error using isset() but the code looks so ugly!
So my question is: What if I go back to my normal settings of error reporting? does it really matter to know that something is not already defined? because it woks properly without the Notice error.
Because i have +10 inputs and i get them like that:
$username = $_POST['username'];
I also tried to pre-define the variables using this in the top on the file.
$username = null; and $username = 0; but they don't work.
Thanks.
It does matter. Errors slow down PHP and you really should design you application not to throw errors. Many other languages will completely die in situations where PHP happily continues script execution.
When developing, your script should not throw any errors (even an E_NOTICE).
I would suggest creating a simple function to grab the $_POST values and do the checking for you.
e.g.
<?php
function getPost($key)
{
return isset($_POST[$key]) ? $_POST[$key] : null;
}
Edit:
Apparently it wasn't clear to the OP how to use this:
$username = getPost('username');
It means there is no key 'username' in the POST array.
Generally, it is a good idea to check and correct these things, as they may ripple to other parts in your application that do depend on the missing value.
It does matter -- when I get strange behaviour in a php application the error log is the first place I look and nine times out of ten an "UNDEFINED INDEX" message leads me straight to the root cause.
Notices do have a purpose: they're a tool to detect potential errors in your code. If you write code that triggers notices for trivial operations and you are not willing to change it, you'll have to disable notice reporting and thus reject a helpful tool on purpose and make your work harder than needed.
Historically, PHP was designed with extreme simplicity in mind (in old versions you'd just have an $username available with zero lines of code) but this approach proved highly inadequate as the web evolved: it only lead to code that was insecure and hard to maintain.
All errors should be addressed, no matter the level, for portability.
If you build your application not addressing strict errors, and your application is deployed on a server that does have strict error reporting, your application is going to fall over pretty quickly.
Your best bet is to check the existence of $_POST['username'] and then act independently on that return value. Using isset() your return value with either be true or false.
I'm guessing $_POST['username'] is for use in an authentication system of some description? Therefore, if your isset() function returns false you could then display an error detailing to the user that username is required.