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]
-~----------~----~----~----~------~----~------~--~---

Reply via email to