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 --~--~---------~--~----~------------~-------~--~----~ NZ PHP Users Group: http://groups.google.com/group/nzphpug To post, send email to [email protected] To unsubscribe, send email to [email protected] -~----------~----~----~----~------~----~------~--~---
