Appropriate places to use '@' symbol

[jasonyoung]

Hello everybody, hope you can help out here.

I'm close to finishing a project and it's about to go production. I have not used the '@' symbol anywhere as I wanted to get EVERY error output during dev, but now I think I'm ready to implement it. The only trouble is, exactly where do I use it?

Can i do a global findfor '$' and replace it with '@$' or is there a more appropriate method. I'm guessing there is.

Thanks.

[laserlight]

Personally, it would be simpler to just set display_errors to Off in php.ini and log_errors to On.

[jasonyoung]

Wish I could, but this is a hosted domain and I don't have control of the underlying file system. Any other ideas?

Thanks for the quick response!

[laserlight]

You should be able to use [man]ini_set/man at the start of your scripts to alter display_errors, I think.

[bradgrafelman]

Or, if PHP is installed as an Apache module, you can use a .htaccess file in the root of your website.

Anyway, the short answer is... you almost never need to use '@'. Instead of suppressing errors, why not fix them? Show us some examples of lines that output error/warning/notice messages without the '@' suppressor.

[jasonyoung]

I ran this

echo 'display_errors = ' . ini_get('display_errors') . "\n";

and got display_errors = 1 so I tried

ini_set('display_errors',0);

and now it shows display_errors = 0, which should be good, right?

Brad, I agree they should be fixed, not swept under the rug, but we're all human and will make errors, so I figured a little safety net wouldn't be too bad an idea.

Perhaps I don't fully understand what the heck I'm expecting to suppress. If I forget to declare a variable with a '$' will the ensuing parse error be suppressed? Maybe I need to go back to the drawing board on this.

Thanks.

[bradgrafelman]

jasonyoung wrote:

I figured a little safety net wouldn't be too bad an idea.

Oh, I'm not trying to say that you shouldn't worry about displaying error messages to the world, but that's where [man]set_error_handler[/man] (to use your own custom-made error handler, which obviously doesn't output paths or revealing error messages) or [man]ini_set[/man] (to turn error displaying off and logging on) come in handy.

jasonyoung wrote:

Perhaps I don't fully understand what the heck I'm expecting to suppress. If I forget to declare a variable with a '$' will the ensuing parse error be suppressed?

If you forget to declare a variable, go back and declare it; that's what the debug/testing phase is for. Once you move the script to your production environment, it's not going to decay and suddenly lose a variable assignment, so I suppose the "fix it and forget it" philosophy would apply here.

Example, this code:

$test = @$_GET['test'];

doesn't need to use the @ error suppressor, as it should instead be written as:

$test = (isset($_GET['test']) ? $_GET['test'] : '');

[laserlight]

and now it shows display_errors = 0, which should be good, right?

Yes, for production code.

If I forget to declare a variable with a '$' will the ensuing parse error be suppressed?

That would be a rather serious mistake, as it would not be a variable but a string (with a warning about it). Just suppressing the error would not do you any good.

More likely we are looking at unusual error conditions which can arise from certain function calls. But if you use the error control operator to suppress such possible errors, then what happens when you want to debug? You have to go through your script and remove those @s, or maintain two versions of the exact same script (and keep them in sync).

You could use @ on incoming variables to suppress the warning about them not existing, but that is better handled by appropriate use of [man]isset[/man], [man]empty[/man] or [man]array_key_exists/man.