Is it best to use @ to stop errors in php code

Hi,

Just wondering for something like:

$com = @ROUND(($cout / $dim * 100), 2);

I get the result, but if both $cout and $dim is 0, then it get a Division by Zero error. So is using @ fine when aiming to stop the visitor from seeing this error in their browser or is it best to use an if statement.

I just want to use as little code as possible. Also if I do use @ would the error in the code still be adding to the error log file as if it does then that log file would get huge and would prefer not to use it then and just use if statement.

Thanks!

It is better to handle the condition properly than to hide the error message. Hiding the error message means your code is still producing an error just that you have chosen to hide it.

if ($dim) $com = ROUND(($cout / $dim * 100), 2);

gets rid of the error completely and is only an extra 7 characters.

Thanks for that.

Suppressing errors with @ is also slow, as PHP changes its error reporting/display, executes the code and changes it back. If you use a lot of @ it can be a performance issue.

Oh no, it cannot.
It is scaring tales for children :slight_smile:
Suppressing errors is just stupid, because leaving programmer without help when it needed. Nothing more.
If you use a lot of @, you already in trouble, much worst than mythical performance penalty. Your app just never grow to have any :slight_smile:

I just want to use as little code as possible.

If you are writing code to achieve the goal and be in safe from every angle (like performance issues and some loop holes around) then you must go in a rule and write the code in some standard way. But if you are only concerned about few lines of code and do the things, this is up to you whether to use or not since PHP has given that facility to suppress the errors. But if you ask about the practice, as fellgall and others said before, never use @ at least until you go to the production server.

What does it mean “until you go to the production server”?
You probably don’t understand what are error messages for.

The slowdown actually occurs from the generation of the error itself.

The slowdown actually occurs from the generation of the error itself.

Oh yes, it does.
Some people just can’t distinguish slowdowns that worth mentioning and ones that doesnt’

When I first started learning PHP the examples for database functions often used the error suppressor. I guess the logic is database errors are independant of PHP and unpredictable. And it is better than outputting error messages on a live site.

Since then PHP now has try/catch, and it is better to use custom error/exception handling.

Of course it does mean writing a bit more code, but as felgall showed, it’s often not that much more.

As I have gotten more into writing WordPress code, I discovered that it uses error suppression quite liberally in it’s core files. So much so that when my error reporting plugin finds errors and I track it down to something that was suppressed, if it’s easily fixed, I submit a trac ticket.

So I guess there may be times when it’s use is acceptable (eg. unanticipated database/filesystem errors), but I strongly believe it should be avoided if at all possible. Seems a bit “lazy” in many instances especially when a simple isset() could prevent an error.

Testing shows that that with @, what takes 1.4 seconds without error reporting takes 2.9 seconds with error reporting.

http://vega.rd.no/articles/php-performance-error-suppression

So let’s avoid this issue and prevent the need for @ in the first place.

Some people don’t know how to test.
And, still can’t distinguish slowdowns that worth mentioning and ones that doesnt’

Hey Mittineague.
Who says “outputting error messages on a live site”?
There are two things to understand with error reporting:

  1. Which messages to show.
  2. Where to output it.
    Many people mess it up.
    There are no difference between development and production servers in which errors to show. It must be the same.
    To control where to output error messages, there are designated setting. Do not mess it with anything else

I mean “at least” :

…at least until you go to the production server.

That means you can use @ to suppress some accidental error messages when you upload the files to production server to be safe but that can also be done by putting the display_error OFF though. But still be sure that I am not recommending to use it but what i think is error messages are not good in production server so I would love display_errors OFF or put @ in front of functions if there are only one or two case(s).

Maybe I don’t know from my last 3/4 years of experience in PHP programming. Can you please tell me why the error messages are for?

Most people just don’t understand what are error messages for, I’d even say.
Anyone who says “use @ on production” or “@ is better than output” is among them.

Can you please tell me why the error messages are for?

With pleasure.
To help a programmer to find an error.

Hey rajug

or put @ in front of functions if there are only one or two case(s).

I don’t understand it. It is impossible to have only 1 or 2 cases.
Literally any function can produce an error. Any line of your code.
So, you have to put @ at each line. It’s nonsense.

Or are you speaking of intentionally left errors?
It is very interesting issue.
The question in the first post of this thread is “To let your code have intentional errors a or not to let?”
The answer can come from proper understanding only.
If you rely on error messages, if you control how your site running with error log, you’d never let any bit of code produce any intentional error message.

Say, without error suppressing there can be notice of undefined variable, if, by some accident, $cout or $dim went undefined. So, you will see this notice and take actions.
With @ you will not see both intentional and accidental error messages.
That’s why @ is evil.

Shrapnel_N5, I am talking in general and what I mean by saying one or two cases in a script is; (this is my own example and way what I have done myself in some projects):

  • Suppose I am deleting a record from database table and that record might have a file uploaded in a path which is optional.
  • Before or after deleting the record from the table, I generally don’t check whether file exists in the file or not I do something like below:

$filepath = '/mypath/to/the/file/';
$id = $db->real_escape_string($_GET['id']);
$filename = $id . '.jpg';
$result = $db->query("DELETE FROM tblname WHERE id=" . $id);
if($result){
    @unlink($filepath . $filename);
}

I don’t think that I am leaving some loopholes and there is performance issue with only this single use of @ in unlink function.

I hope I described clearly why I said one or two cases.

To be honest, I find it boils down to whether you actually handle the error mentioned rather than your decision to suppress it.

For instance…


<?php
if(false === @preg_match($pattern, $subject)){
    throw new InvalidRegExpException($pattern);
}

…I suppress the error, but handle it with a more manageable implementation.