Your example pretty much handles the same as using a ternary, with an exception.
Example:
$something = (isset($_GET['something'])) ? $_GET['something'] : null;
if ( !$something )
{
// do something
}
This will produce the same result as your example, but cannot produce any
errors (unless you mistype :P) that could/would be suppressed when using your
example - therefore, more strict/compliant code
The @ operator definitely has its place - I just don't agree with using it to
suppress missing key notices. (each to their own I guess)
An example of where the @ operator works well is the fopen() function.
Example:
// create the handle
$fileHandle = @fopen("/path/to/file"); // returns false on fail. Suppressing
the standard ghastly PHP error notice that can encroach on your well designed
page layout
// check we have a valid handle
if(!$fileHandle){
// gracefully display a "can not open file" error
}
As said previously, there are many ways to do things - I just prefer to do mine
compliantly :)
~ C
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Sid Bachtiar
Sent: Wednesday, 16 September 2009 5:47 p.m.
To: [email protected]
Subject: [phpug] Re: PHP 5.3.0 error
Using @ does not mean you're not handling errors. And not using @ does
not mean you are handling errors.
Consider this:
$something = @$_GET['something'];
if ( !$something )
{
// do something
}
// more validation on $something here ...
Another example:
http://thesmithfam.org/blog/2006/05/07/php-the-operator/
On Wed, Sep 16, 2009 at 5:27 PM, Hamish Campbell <[email protected]> wrote:
>
> On Sep 16, 4:14 pm, Cliff Black <[email protected]> wrote:
>> Are you serious?
>>
>> A mistype does not constitute a programming error.
>>
>> That's like saying "I meant to enter preg() but instead I typed ereg()"
>> We've all done it... lots! (and I know I'll do it lots more too! Haha)
>
> Ha, didn't catch the mistype. I assumed Craig was referring to the
> fact that isset($_GET["q"]) returns false if the *value* of the $_GET
> ["q"] is not set ( = null).
>
> So, for example:
>
> $data = array("a" => 1, "b" => "banana", "c" => null);
> $exists = isset($data["c"]); // false
> $exists = array_key_exists("c", $data); // true
>
> However, it is worth nothing that Craigs example actually proves your
> point. If a value is not supplied you get an error that is very easy
> to debug (if you get an error that $_GET["foo"] doesn't exist, but you
> see the isset statement, you immediately know the problem). However,
> if you mistyped this:
>
> $data = @$_GET['too']; // should actually be foo
>
> Well, you've already anticipate the non-existance of 'foo', so you
> don't get an error when it doesn't exist. This is the bigger fail, and
> demonstrates why error suppression is a bad idea.
>
> >
>
--
Blue Horn Ltd - System Development
http://bluehorn.co.nz
--~--~---------~--~----~------------~-------~--~----~
NZ PHP Users Group: http://groups.google.com/group/nzphpug
To post, send email to [email protected]
To unsubscribe, send email to
[email protected]
-~----------~----~----~----~------~----~------~--~---
