Being that isset is a language construct and array_key_exists is a function
the former is supposed to be a faster way of determining existence.
Please don't suppress errors or notices with the @ operator.  It is much
better to drop the error reporting level down that way you only need to
change one thing to show the errors again if you need to debug.  Hunting
through reams of legacy code to find an error is so much more difficult if
people have used the @.

2009/9/16 Sid Bachtiar <[email protected]>

>
> Sure, I'm not arguing for the user of @ either. I use Symfony, I don't
> even use $_GET anymore. I prefer $something =
> $request->getParameter('something');
>
> By the way, I tried the following and it did not raise any error (php 5.26)
>
> <?php
> error_reporting( E_ALL | E_STRICT );
> $something = @$_GET['something'];
>
>
>
> On Wed, Sep 16, 2009 at 6:19 PM, Cliff Black <[email protected]> wrote:
> >
> > 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
> >
> >
> >
> > >
> >
>
>
>
> --
> Blue Horn Ltd - System Development
> http://bluehorn.co.nz
>
> >
>


-- 
Simon Holywell
http://www.simonholywell.com

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