The only use I have ever found for @ is suppressing errors in external libraries you are forced to use.
Instead of using @ with fopen you should check before whether the resource exists and that it is possible to operate on it how you intend to, e.g. read, write. Hamish raised a good point :) it is slower to use @ then checking the variable/array index. What you end up doing is creating code that is harder to read > and the complexity just masks other higher-level errors and makes the > code more difficult to maintain. I don't understand what you mean here when you say "masks other higher-level errors" I disagree that it makes the code more difficult to maintain. Variable checking shouldn't affect code readability and maintainability (I find it usually improves it). The main issue I have with @ actually comes from my past experience working with some cowboys poorly written code. Although @ might have some uses, such as in email addresses and doc blocks :), it is something I often come across while fixing crappy code. But there are real problems too. I'll try an example: if( @some_expensive_fn($_GET['something']) ) vs. if( isset($_GET['something']) && some_expensive_fn($_GET['something']) ) If people get into the habit of using @ it could lead them to use this kind of sloppy code. Cam On Wed, Sep 16, 2009 at 8:21 PM, Simon Holywell <[email protected]>wrote: > 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] -~----------~----~----~----~------~----~------~--~---
