In php using @ instead of isset
In some conditions, may I use an @
character instead of using the longer isset()
function?
If not, why not?
I like to use this because in a lot cases I can save several quotation开发者_StackOverflow marks, brackets and dots.
I assume you're talking about the error suppression operator when you say @
character, but that isn't a replacement for isset()
.
isset()
is used to determine whether or not a given variable already exists within a program, to determine if it's safe to use that variable.
What I suspect you're doing is trying to use the variable regardless of its existance, but supressing any errors that may come from that. Using the @
operator at the beginning of a line tells PHP to ignore any errors and not to report it.
The @
operator is shorthand for "temporarily set error_reporting(0)
for this expression". isset()
is a completely different construct.
You shouldn't just use an @
. The @
suppresses warnings. It doesn't mean the code is correct, and warnings might still get added to your log file depending on your settings. It is much better to use isset
to do the check.
As far as I know @
is no substitution for isset()
. Its an error suppression operator which prevents displaying errors in case they do exist in the script. Its also a pretty bad habit if used in PHP code.
It technically works, but there are a few reasons why I prefer the explicit isset
solution when creating output, which I assume is what you're doing:
- If I'm a new developer working on your old code, I recognize the
isset
idiom. I know what you're trying to do. With@
, it's not so easy to figure out your intention. - Suppose you want to check if an object's property is set, like
$user->name
. If you just use error suppression to see ifname
is set, you will never be notified if$user
is undefined. Instead, it's better to runisset($user->name)
and be explicit, so that, if$user
is undefined, you will be notified of the error. - Error suppression is a bad habit overall. Error notices are good, and you should make it as easy as possible to be notified of errors. Suppressing them when it's not necessary leads to problems in the future.
It depends on what you are trying to do. For instance, if you are performing a var_dump() or other debugging and know that sometimes your value will not be set I'd say in this situation it is ok.
var_dump(@$_REQUEST['sometimesIamSet']);
If you are using it in this case:
if(@$_REQUEST['something']){
// do something
}
else{
// do something else
}
I would strongly advise against it. You should write your code to do explicitly what you want to do.
if(isset($_REQUEST['something'])){
// Hurray I know exactly what is going on!
}
else{
// Not set!
}
The only instance in production I can think about using @ is when you want to throw your own error. For example
$database_connection = @db_connect_function();
if($database_connection === false){
throw new Exception("DB connection could not be made");
}
Also, look at PaulPRO's answer. If what he is saying is indeed true, your log files could also be logging warnings that you don't know about. This would result in your log files being less helpful during debugging after release.
If for no other reason, don't use @ as a substitute for isset because of this:
Look at this code:
echo (@$test) ?: 'default';
If $test is 'something'
then you'll get 'something'
.
If $test is empty, null
or doesn't exist, then you'll get 'default'
;
Now here's where the problem comes in:
Suppose '0'
or FALSE
are valid answers?
If $test is '0'
or FALSE
then you'll get 'default'
NOT '0'
as you would want.
The long-format ternary is what you should use:
echo (isset($test)) ? $test : 'default';
Not much more coding, and more reliable when it comes to dealing with arguments that can evaluate as boolean false.
the @
operator also makes your code run slower, as pointed out here:
http://php.net/manual/en/language.operators.errorcontrol.php
But as it's been pointed out, the code only runs measurably slower if an error occurs. In that case, code using isset instead of @
operator is much faster, as explained here:
http://seanmonstar.com/post/909029460/php-error-suppression-performance
精彩评论