O'Reilly

Suppressing PHP Errors & Warnings Using @

By on  

One part of making sure your website is secure in its hosting environment is to handle errors in a good fashion. If you don't have complete control of your hosting environment, you don't know what you can expect in the way of error handling if you don't do everything you can think of.

One method I use in all of my programming is to place an '@' character in front of function calls that have potential for returning warnings or errors.

@require($_SITE['ROOT'].$_FOLDERS['CONTROL'].'logger.php'); // suppress a file not found error
@mysql_connect($host,$user,$pass); // suppress no connection error

I recommend using the @ once your website is in production. I generally don't use the @ on development servers because I want to be aware of errors during development.

Track.js Error Reporting

Upcoming Events

Recent Features

  • Designing for Simplicity

    Before we get started, it's worth me spending a brief moment introducing myself to you. My name is Mark (or @integralist if Twitter happens to be your communication tool of choice) and I currently work for BBC News in London England as a principal engineer/tech...

  • Write Simple, Elegant and Maintainable Media Queries with Sass

    I spent a few months experimenting with different approaches for writing simple, elegant and maintainable media queries with Sass. Each solution had something that I really liked, but I couldn't find one that covered everything I needed to do, so I ventured into creating my...

Incredible Demos

Discussion

  1. Quick Update: Doing this is not recommended for large web applications as it can be very expensive.

  2. This is the worst advice I’ve ever heard. This is an old post so I assume (hope) you realise that now, but it ranks very highly on Google, so if you just got here from a search:

    DO NOT DO THIS

    Errors are thrown for a reason, David is correct that displaying them to end-users is incorrect (it’s messy and potentially a security issue), and that errors should be correctly handled. Ignoring is not handling! You can set your php.ini for production and turn off displaying errors, logging them instead, and you can create a custom error handler for more advanced things. Whatever you do, don’t just ignore them!

    • FredWallace

      As he points out, some people may not “have complete control of [their] hosting environment”. That means not everyone has the luxury of editing php.ini.

    • Nemo

      “Worst advice I ever heard” is a very harsh comment. In the right context the @ trick can be very useful.

      Take for instance the getimagesize function that returns size and other information for an image file. The nice thing about it is that it can work with a URL. But what if the URL is no longer valid? It throws up an error. It is far more elegant to simply absorb that error with an @getimagesize and then detect it by checking to see if the length of the “array” returned is less than 7.

      Thank you, David. I have used @ once or twice but I always have to hunt around for it each time I need it.

    • Stephen

      Whilst errors should be handled properly it’s impossible to plan for everything that might go wrong. In that case it would be better to suppress the error on a production site than publicly reveal details about the site’s inner workings.
      As stated by others, people might not have control of their php.ini file but it should be noted that errors can be supressed throughout the rest of the script with:
      ini_set(‘display_errors’, 0);

    • He was writing this from the perspective of people who have no other choice. For example, on a shared hosting environment you’re not likely to have any control over php.ini, so you can’t change those settings. This is, of course, different if dealing with a VPS or dedicated server.

    • zofrex

      There are still other workarounds that are better than this, you can add custom error handlers without needing php.ini access.

      The problem with doing this is it will squash all errors and send them into /dev/null, and your script will keep on running merrily and then probably explode at a later point, making it very difficult to track down where the actual issue is.

  3. Neo

    Cool, never thought about that! This will work great in my CLI scripts ;)

    Thanks

  4. jeff

    Agree with the statement this is very bad advice. Following this will likely leave you hunting bugs and running wild.

    Usually good advice found here. Updating this blog post would be a VERY good idea, since it ranks so high!

  5. Patrick D

    Super helpful, thanks. I don’t necessarily agree with the other comments on here – I think you should just note that this should only be used with great caution and only when absolutely necessary. If there’s another way to approach it, that’s probably preferred, but there are absolutely times when you have to whip this out.

  6. Well, this was useful, when try-catch doesn’t (seem) to work.
    I see lots of comments about avoiding this, but imagine the following…

    You have a webpage, A, that is displaying a PHP image, B. B loads another PHP image, C, and then adds/overlays some graphics ontop. B picks up a random file from a directory and sends information from this file to C. C then reads this information and gets to work on generating an image. Now, if the processing of this file exceeds the Maximum Allowed Memory you can use and you can’t do anything about that, C will return a FATAL ERROR which is recived by imagecreatefrompng, which will return a Warning, and A won’t be able to show the image because it won’t understand a “Warning” image format. Deciding that C can be ignored, but the rest of B is a little more important, I tried to try-catch, but it still displayed the warning. Now I know of @, seems easier… Yeah, I’m lazy, maybe I should wrap that imagecreatefrompng in some custom error handler. That way I might later print the error message onto the B image.

    /Edward

  7. Hari Rao

    Hi David,

    I spent to much time in finding where the problem is but your technique is really awsum. This has helped me to narrow down where the issue is.

    Thanks
    Hari

Wrap your code in <pre class="{language}"></pre> tags, link to a GitHub gist, JSFiddle fiddle, or CodePen pen to embed!

Recently on David Walsh Blog

  • OâReilly Velocity Conference â New York

    My favorite front-end conference has always been O'Reilly's Velocity Conference because the conference series has focused on one of the most undervalued parts of client side coding:  speed.  So often we're so excited that our JavaScript works that we forget that speed, efficiency, and performance are just as important. The next Velocity...

  • Free Download: Font Bundle Featuring 17 Incredible Typefaces

    The only thing we love more than a good font, is a good free font. So we’ve combed the Web for some of our favorite free fonts, and gathered them here in a single download. You’ll find a variety of useful typefaces, from highly geometric designs...

  • OâReilly Velocity Conference â Amsterdam

    My favorite front-end conference has always been O'Reilly's Velocity Conference because the conference series has focused on one of the most undervalued parts of client side coding:  speed.  So often we're so excited that our JavaScript works that we forget that speed, efficiency, and performance are just as important. The next Velocity...

  • CanIUse Command Line

    Every front-end developer should be well acquainted with CanIUse, the website that lets you view browser support for browser features.  When people criticize my blog posts for not detailing browser support for features within the post, I tell them to check CanIUse:  always up to date, unlike...

  • Generating Alternative Stylesheets for Browsers Without @media

    If your CSS code is built with a mobile-first approach, it probably contains all the rules that make up the "desktop" view inside @media statements. That's great, but browsers that don't support media queries (IE 8 and below) will simply ignore them, ending up getting the...