When should error suppression be used?

[james438]

When incorporating code from other sources I sometimes see it utilizing error suppression (@). For debugging purposes I turn it off and often find it unnecessary. I think that it is nice to have options with php like error suppression, but I can't figure out when it would be useful. Where/when should it be best used?

[djr33]

It's generally a bad idea, sort of like exec() or output buffers. But there are also exceptional times when you need it.

One requirement: the errors you are suppressing are not important-- sometimes PHP stops executing (or maybe gives a warning) for an important reason, and you should not ignore it. So only do this when you're certain there aren't any important errors. And be aware that error suppression is hierarchical-- if you have any functions/includes/loops/etc. it will apply to everything within that scope as well, so be careful you don't ignore any warnings that might matter but aren't obvious.

I can think of two reasons you would want to do this:
1. You may encounter errors but want to deal with them yourself. Perhaps you want to make a "friendlier" error message for visitors like "Oops. This page had a problem. Please try later." instead of PHP gibberish. (And in debug/admin mode, you could display more info or the original message.) You can usually do this by using error suppression and code like "if (@function()===FALSE) { echo 'ERROR'; }".

2. Some PHP functions give errors if you try something and it doesn't work. Maybe you want to try it, without giving an error. An example would be a case where a user has control over something (such as entering an FTP/MySQL password) and you don't know if it will work. If you expect failure, then you should probably ignore those error messages (and come up with your own custom error handling).


In short, most of the time you're doing something wrong if you use error suppression. Sometimes it can help, though. If you've got a good reason, go ahead. A good rule of thumb is that you should be doing your own error checking if you're not using default errors.



As for seeing it in other scripts, there are four options:
1-2: as above, there's a legitimate reason
3: it's bad code (not that uncommon!)
4: they're trying to make it compatible with as many servers as possible, and it's easier (lazier) to write code that won't give errors if a server isn't compatible rather than including lots and lots of checks along the way to see what the right option is-- but that's lazy, sort of like relying on an undefined variable, etc.

[james438]

That makes sense. Security sounds like it would be a good reason for me to use error suppression now and again.

[djr33]

Security sounds like it would be a good reason for me to use error suppression now and again.

I'm not sure about that. It's probably better to actually turn off error reporting, which is common practice for the final version of a website that is live for users.
For debugging, you'd turn that (back) on and might use @ if there's some kind of specific error that might come up.
(Some of my comments above might have sounded contradictory to that-- I wasn't really thinking about it in that way.)

The PHP manual says:

Currently the "@" error-control operator prefix will even disable error reporting for critical errors that will terminate script execution. Among other things, this means that if you use "@" to suppress errors from a certain function and either it isn't available or has been mistyped, the script will die right there with no indication as to why.

I was under the impression that it would allow you to skip past any "critical errors" as well. It looks like it doesn't. Now I can't remember the exact situations I was using it for, but I thought that it would actually let you do something like:
@function_that_does_not_exist();
without crashing PHP. (I've just tested this, and in fact it just suppresses the error and gives a blank page, but still stops execution.)

It's probably worth reading about it here:
http://php.net/operators.errorcontrol

Note that some PHP functions recommend (according to the manual) the use of error suppression if you don't want it to give an error. And example is fopen(), which gives an error if the file can't be read. However, note that it's a case of an "extra" error, just a warning really, not a fatal error (which would still crash the script). So assuming you have plenty of checks in place, there wouldn't be much wrong with @fopen(), but the rest of your script might behave oddly and it wouldn't make sense if you don't have some equivalent.


There are a lot of comments here. I got bored reading all of them, but there are some good points (at least toward the top)
http://stackoverflow.com/questions/136899/suppress-error-with-operator-in-php



Finally, I just thought of another case where I do use error suppression:
When I'm using a third-party script that may have some issues, I might use error suppression for the highest level function wrapping that. Let's say you create a function like do_third_party_thing1() for some kind of repeated action (I've done that, for example, with GeoIP to look up information about an IP in the format I'd like). Then if that script has any potential issues that you don't want to deal with, suppressing the errors can be fine. It might not work. But you can check that Obviously the best thing would be to rewrite the whole third-party script. But sometimes it's not worth it.



However, I'd like to hear what traq has to say about this. Based on his comments in the other thread, he seems to dislike error suppression more than I do, and I'm open to that. Just wondering why.

[traq]

However, I'd like to hear what traq has to say about this. Based on his comments in the other thread, he seems to dislike error suppression more than I do, and I'm open to that. Just wondering why.

hehe

Well, the main thing I "dislike" about it is how badly it's misused much of the time.
In general, when you finish writing a script, it should not produce any PHP errors (there might be errors, like invalid user input, or a non-existent file - what I'm talking about is PHP Notices, Warnings, Errors, or Fatal Errors).

Unfortunately, PHP is designed in such a way that that's not always possible, or -in some cases- it's actually more efficient not to check. Take this, for example:

<?php

$contents = file_get_contents( 'somefile' );

What if "somefile" doesn't exist? You'll get an error. In this case, you'll get an error with a message that spits out a good portion of your server's directory structure - not good for security!

Typical, 'correct' solution:

<?php

$contents = null;
if( file_exists( 'somefile' ) ){
    $contents = file_get_contents( 'somefile' );
}

This is much better for security and user experience. However, you now have two function calls for doing only one thing. If almost all of your files exist, you're wasting a lot of time. In fact, it's still slower to check first if the file doesn't exist.

People will tell you that @ is very slow, and they're right. But it's still much faster than file_exists and file_get_contents (a bit slower than no error suppression on a valid file; seven times faster on an invalid file):

<?php

$contents = null;
$contents = @file_get_contents( 'somefile' );

There's also some things you simply can't do without it. Suppose a user wants to do some pattern-matching and gives you a regex. The only practical way to test a regex in PHP is to try to use it, but preg_match will throw an error if the regex isn't good. So:

<?php

$valid = @preg_match( $unknown_regex,"" );

In any case, I'm mostly using exceptions for error-handling now. They're nice ...overkill in most situations, but they work with object-oriented stuff much more easily.

[djr33]

Well, the main thing I "dislike" about it is how badly it's misused much of the time.
In general, when you finish writing a script, it should not produce any PHP errors (there might be errors, like invalid user input, or a non-existent file - what I'm talking about is PHP Notices, Warnings, Errors, or Fatal Errors).

Agreed. The trouble is that some of those can lead to PHP errors (invalid user input, etc.). Or potentially uncertainty on the server (eg, a file management system where a file might or might not exist-- sort of still user input, but a different perspective on it) -- probably one reason that some third-party scripts use @ a lot.

Unfortunately, PHP is designed in such a way that that's not always possible, or -in some cases- it's actually more efficient not to check. Take this, for example:

Right.

There's also some things you simply can't do without it. Suppose a user wants to do some pattern-matching and gives you a regex. The only practical way to test a regex in PHP is to try to use it, but preg_match will throw an error if the regex isn't good. So: [...code...]

Ah, yes, good example. That's the kind of thing that PHP really does force you to use @ for, I think. That was similar to an eval() example I saw in the stackoverload link above.

In any case, I'm mostly using exceptions for error-handling now. They're nice ...overkill in most situations, but they work with object-oriented stuff much more easily.

Hm, something else to add to my list of "I should look into that"


Note: this other thread is a related conversation. I'll add a link in case anyone wants to refer to that in the future:
http://www.dynamicdrive.com/forums/s...he-main-script