what does @ in front of a function mean?

Example:
@ini_get()

It supresses the error/warning that the function may display to the browser

what does @ in front of a function mean?

Example:
@ini_get()

Like the person above me said, it supresses the errors/warnings generated from showing in the browser for the function you put it in front of.

For example:

$sql = @mysql_query("SELECT id from tabletest WHERE user='$user' limit 1");


If it can't select an ID from the table for whatever reason, it wouldn't show the error in the browser(possibly breaking the layout or giving directory/SQL details that you might not want them to see). This is useful when you know that under certain circumstances it may not always successfully run the SELECT statement.

Handy little function when you get some annoying warning/error messages, of course this is no substitute for bad coding.

it supresses the errors/warnings generated from showing in the browser for the function you put it in front of.More accurately - it suppresses PHP errors for expression.

@ = error-control operator prefix

So if your PHP server is configured to display messages in the browser, with @ it wont. And if you have PHP set to create error logs, any expression with @ in front of it wont create an entry in the error.log file either.


Be careful with it though as it can hinder fault finding.
It will disable error reporting for even critical errors that will terminate script execution, so typos and other often easy to find problems with errors wont be reported to screen or log file and are then hard to debug.

Typically you should use error reporting to a log file anyway IMO. You don't want errors showing to the screen on a live/public site for visitors to see, ugly and potential security risk.
So if avoiding using @ in development to allow for debugging AND displaying errors to the browser means you then have to go through all your code and add @ to everything you want, which isn't great. Which is why I use error.logs.

You can actually email errors if you so desired. Although as DHD-Chis said, "this is no substitute for bad coding" and I'd be worried if I had to rely on my sites emailing me whenever there was an error.


Have a read of this:
http://www.php.net/manual/en/language.operators.errorcontrol.php

And this
http://www.php.net/manual/en/ref.errorfunc.php

I've honestly never seen a legitimate use for it. It is also an extremely slow operation, as it really does temporarily turn error reporting off and then back on again.

I can think of 2.
1) Your web host has errors on and you don't want any showing.
2) Some function will generate an error even if you check for it i.e. mkdir(),fopen()

3) if you're trying to crawl some sites for whatever reason, connection errors might happen, and some errors could happen that you can never control

nothing is done without any need

I can think of 2.
1) Your web host has errors on and you don't want any showing.


Can be changed at runtime.

2) Some function will generate an error even if you check for it i.e. mkdir(),fopen()

This is what functions like fileowner, file_exists, filegroup, and fileperms are for.

3) if you're trying to crawl some sites for whatever reason, connection errors might happen, and some errors could happen that you can never control

This does not necessarily result in php errors, as long as code is properly trapped.

even if the code is properly trapped, some errors happen before u seeing them... so u use the @ to ensure it

Again as DHD-Chris said, there is no substitute for bad coding.

You should be avoiding any errors from being output, such as checking if something is an array BEFORE running a foreach on it.

That said, there are circumstances out of the control of the coder.
You can have something like
$db_connection = @mysql_connect($db_host, $db_user, $db_password);If the database gets renamed, corrupted, moved, not accessible, etc, or the user or password is changed (hosts can change db passwords for security reasons) without the @ on the mysql_connect you will get an error.
Others are mysql_query, mysql_num_rows etc. If for some reason a table name gets altered or isn't accessible then running the above code will result in an error, something like: mysql_num_rows is an invalid result resource blah..

It isn't always about bad coding or even being a good coder and having code that avoids errors. There are outside influences beyond you control, and therefore using the @ in places where problems can happen makes you a good coder!

I'm not saying use it everywhere. Like Veks said, you should be using things like is_dir, is_array, if !empty etc

Seems to me that intelligent use of exception handling and doing something with them might be a better approach. Some - like legitimately returning no rows or some such thing - are conditions that one expects to see and thus the application should continue.

But others - like a database password change which causes the entire site to break - should be allowed to break the site (and trigger a notification to the sysadmin) or caught and intelligently handled (like presenting an "off line" page and notifying the sysadmin).

On a development machine, you want to display *uncaught* to the developer/QA person.

On a public machine, un-caught exceptions (or intelligently caught exceptions) get send as an email to your site admin/developer. An uncaught exception is an "exceptional circumstance", one they should be alerted to, instead of pretending all is well. In Python we might do something like:

try:
user = get_user(email_address)
except DatabaseException as e:
notify("get_user failed retrieving email_address", e)
return system_offline()
# all is well, carry on
do_foo_with_user(user)

Or, more commonly in Python these days, a web framework will capture uncaught exceptions for you and put up your "I'm sorry page" to the user, while notifying the sysadmin, so all you are left with is writing the core logic:

user = get_user(email_address)
do_foo_with_user(user)

In PHP I suppose the best advice is to be consistent in how you handle the unexpected.

In PHP I suppose the best advice is to be consistent in how you handle the unexpected.
You have to draw a line somewhere otherwise it would take forever to complete code.
I'm not suggesting cutting corners, some things are a must, like security (real_escape etc).
But with having something like an exception for a database connection, it's more coding time and more resource usage for the server.

In most practical environments you would expect that mysql_connect is going to find and successfully connect to a database, and mysql_query is debugged in development, the table exists, the queried fileds exist and contain data as required (of course still with a clause where if rows <=0 etc.)

So, using an @ on mysql_connect is simply a backup that more than likely will never be used. It's not supposed to be a useful alternative to informing admin, site owner or site visitors there was an issue please try again etc, it's simply to stop PHP errors being reported to site visitors.

<If can connect then do stuff else email admin blah etc> is a waste of resources and time to code in 99% of cases as usually DB connections will work.
If you are having db connection problems on a regular basis then you need to look elsewhere for solutions.

And mostly scripts don't rely on a connection for something that would be detrimental without a connection anyway, as you would likely have something in place within the script to avoid that.
Such as "Sorry my product could be displayed" "sorry we could log you in please try again" etc


I have built many websites, and manage many still, and don't think in the past few years a database wasn't connectible.
Apart from if the entire site is down, but then the code wont be accessed and executed anyway.

I have built many websites, and manage many still, and don't think in the past few years a database wasn't connectible.

That's funny, I've seen a great many PHP sites respond with HTTP 500 errors, commonly variations of:

"Fatal error: Out of memory"
"MySQL: Too Many Connections"
"Database Error: Unable to connect to the database:Could not connect to MySQL" (joomla sites)

and so on. Once upon a time you'd see such page results show up in web searches by the hundreds of thousands but for some time now search providers have filtered out 500 errors it seems.

<If can connect then do stuff else email admin blah etc> is a waste of resources and time to code

If your object or library routines call it once, and you call those routines not the raw connect, you've got all the protection and none of the additional work.

Better yet if your web framework is designed to trap uncaught exceptions, then you can allow the framework to catch these and notify appropriately.

I grab my database object and work with it. I don't need to deal with thinking about these exceptions because if the DB should die and a transaction is not completed, it won't be committed. And I'll get a note or a page about the situation. Its no extra work at all to get this; write the routine / framework once, use many, many, times thereafter.

in 99% of cases as usually DB connections will work. If you are having db connection problems on a regular basis then you need to look elsewhere for solutions.

While we have been talking about DB connections my point is not specific to working with a DB. There are many things in a typical web app that can go wrong that should not be silently tolerated.

In PHP "@", wantonly applied, is as dangerous and foolhardy as the following, applied without discrimination, in Python:

try:
do_something_that_might_fail()
except:
pass # do nothing

The above example is particularly bad, and difficult to debug, if a big block of code is within the try block.

To each his own, I suppose. I like to sleep at night, knowing that my apps will keep me informed of bad juju happening.

for me nothing goes unseen... I never put the @ before testing... I write the code I test the site I see the errors that could happen and put comments, then I use the @ so that I can continue working (before using time on error handling) and when time is good (I'm on schedule and have nothing to do, or I am faster than the schedule) I handle the errors... I am not talking about simple code, I am talking about complex code which needs to be done on time

I get your point.

To each his own, I suppose. I like to sleep at night, knowing that my apps will keep me informed of bad juju happening.
I sleep easy as I know mine will work :stickout:

I subscribe to the philosophy that all code is $hit. Mine too. Vainglorious conceit as to the quality of one's code will not hide the true smell.

I sleep well knowing that my mistakes will be picked up.

Hmm, truth be known, I don't need mine to tell me when it doesn't work, I don't usually get any sleep :D

And don't try to impress me with your big words! I have a GCSE in Home Ec

for me nothing goes unseen... I never put the @ before testing... I write the code I test the site I see the errors that could happen and put comments, then I use the @ so that I can continue working (before using time on error handling) and when time is good (I'm on schedule and have nothing to do, or I am faster than the schedule) I handle the errors... I am not talking about simple code, I am talking about complex code which needs to be done on time

I have complex code which needs to get done on time too. Except I don't cut corners - I solve the problem.

And don't try to impress me with your big words! I have a GCSE in Home Ec

LOL!!!!!!!!!!!!

I have complex code which needs to get done on time too. Except I don't cut corners - I solve the problem.

what if you're reading an xml file from another site, and it has errors? how would you solve this problem? You contact the site that owns the xml file telling him to fix his file? or you stop reading all other files to fix what's happening with this file (if you can fix it)?

it's a known project management way called: Do it twice - Quickly and correctly.

First time: do it quickly (for sure working) which will help you in gaining market share and money to be able to survive

Second time: do it correctly which will be the end product that will remain and you'll be able to build over

I am not saying that's the perfect neither that it's not risky, BUT no risk no gain:D I accept the risk

what if you're reading an xml file from another site, and it has errors? how would you solve this problem? You contact the site that owns the xml file telling him to fix his file? or you stop reading all other files to fix what's happening with this file (if you can fix it)?

It depends on the situation. I may be parsing it with a regular expression, in which case I have caught and handled all errors appropriately.

If I'm using the XMLReader class, I make use of php's exception handling. The same would go for mysqli in php 5.3.

it's a known project management way called: Do it twice - Quickly and correctly.

First time: do it quickly (for sure working) which will help you in gaining market share and money to be able to survive

Second time: do it correctly which will be the end product that will remain and you'll be able to build over

I am not saying that's the perfect neither that it's not risky, BUT no risk no gain I accept the risk

As long as your clients are aware of that.

what if you're reading an xml file from another site, and it has errors? how would you solve this problem? ...

He wouldn't solve it; it's not his problem.

Eh, sometimes it can be, like if you go sitemap trolling and really want to map a number of sites.

"Why are you doing that in php!?" <- I don't. I do it in python, but this is a php thread : )

It depends on the situation. I may be parsing it with a regular expression, in which case I have caught and handled all errors appropriately.

If I'm using the XMLReader class, I make use of php's exception handling. The same would go for mysqli in php 5.3.



As long as your clients are aware of that.

Clients has nothing to do with that! I never do a site this way for a client, this way for me and my own projects that I take all the decisions for, clients have the right to take the best project from the first time no way else, or I'll risk losing them!