hosted by liquidweb


Go Back   Web Hosting Talk : Web Hosting Main Forums : Programming Discussion : php question...
Reply

Forum Jump

php question...

Reply Post New Thread In Programming Discussion Subscription
 
Send news tip View All Posts Thread Tools Search this Thread Display Modes
  #1  
Old 04-04-2009, 02:41 PM
yah0m yah0m is offline
Disabled
 
Join Date: Mar 2009
Posts: 155

php question...


what does @ in front of a function mean?

Example:
@ini_get()



Sponsored Links
  #2  
Old 04-04-2009, 02:47 PM
Unquantifiable Unquantifiable is offline
Junior Guru Wannabe
 
Join Date: Jul 2008
Posts: 45
It supresses the error/warning that the function may display to the browser

  #3  
Old 04-04-2009, 06:04 PM
CorvetteX CorvetteX is offline
Temporarily Suspended
 
Join Date: Apr 2009
Posts: 21
Quote:
Originally Posted by yah0m View Post
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:
Quote:
$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.

Sponsored Links
  #4  
Old 04-04-2009, 06:06 PM
DHD-Chris DHD-Chris is offline
Junior Guru Wannabe
 
Join Date: Oct 2008
Posts: 84
Handy little function when you get some annoying warning/error messages, of course this is no substitute for bad coding.

__________________
Anyone like to play games? check out http://www.buttonbashers.co.uk

██http://www.DataHostDirect.com Celebrating 6 months in business! 25% off for life! Shared, VPS and Dedicated Servers(Managed) ██
██20 minute average wait time on Support Tickets. With 24/7/365 Support██

  #5  
Old 04-04-2009, 07:33 PM
greg2007 greg2007 is offline
WHT Addict
 
Join Date: Mar 2007
Location: UK
Posts: 156
Quote:
Originally Posted by CorvetteX View Post
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/languag...rorcontrol.php

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


Last edited by greg2007; 04-04-2009 at 07:39 PM.
  #6  
Old 04-05-2009, 03:00 AM
Veks Veks is offline
WHT Addict
 
Join Date: Jul 2008
Posts: 130
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.

  #7  
Old 04-05-2009, 05:44 AM
Steve_Arm Steve_Arm is offline
Community Guide
 
Join Date: Jan 2006
Location: Athens, Greece
Posts: 1,479
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()

__________________


  #8  
Old 04-05-2009, 06:37 AM
Codebird Codebird is offline
Aspiring Evangelist
 
Join Date: Dec 2007
Location: Lebanon
Posts: 413
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

__________________
Hicham

  #9  
Old 04-05-2009, 07:09 AM
Veks Veks is offline
WHT Addict
 
Join Date: Jul 2008
Posts: 130
Quote:
Originally Posted by Steve_Arm View Post
I can think of 2.
1) Your web host has errors on and you don't want any showing.
Can be changed at runtime.

Quote:
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.

Quote:
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.

  #10  
Old 04-05-2009, 07:34 AM
Codebird Codebird is offline
Aspiring Evangelist
 
Join Date: Dec 2007
Location: Lebanon
Posts: 413
even if the code is properly trapped, some errors happen before u seeing them... so u use the @ to ensure it

__________________
Hicham

  #11  
Old 04-05-2009, 10:36 AM
greg2007 greg2007 is offline
WHT Addict
 
Join Date: Mar 2007
Location: UK
Posts: 156
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
Code:
$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


Last edited by greg2007; 04-05-2009 at 10:41 AM.
  #12  
Old 04-05-2009, 12:47 PM
mwatkins mwatkins is offline
Web Hosting Master
 
Join Date: Nov 2001
Location: Vancouver
Posts: 2,416
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:

Code:
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:

Code:
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.

__________________
“Even those who arrange and design shrubberies are under
considerable economic stress at this period in history.”

  #13  
Old 04-05-2009, 02:25 PM
greg2007 greg2007 is offline
WHT Addict
 
Join Date: Mar 2007
Location: UK
Posts: 156
Quote:
Originally Posted by mwatkins View Post
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.

  #14  
Old 04-05-2009, 02:52 PM
mwatkins mwatkins is offline
Web Hosting Master
 
Join Date: Nov 2001
Location: Vancouver
Posts: 2,416
Quote:
Originally Posted by greg2007 View Post
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.

Quote:
<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.

Quote:
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:

Code:
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.

__________________
“Even those who arrange and design shrubberies are under
considerable economic stress at this period in history.”

  #15  
Old 04-05-2009, 03:49 PM
Codebird Codebird is offline
Aspiring Evangelist
 
Join Date: Dec 2007
Location: Lebanon
Posts: 413
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

__________________
Hicham

Reply

Related posts from TheWhir.com
Title Type Date Posted
Emerging Tech: Email, Security and Privacy Blog 2013-08-29 11:29:43
UK Tech Blog Challenges CloudFlare, Web Hosts on Free Speech Blog 2013-08-12 10:32:52
The Value of Your Intellectual Property Blog 2013-05-06 17:43:13
Joomla Hosting Study Shows Speed, Uptime Top Selling Points of a Web Host Web Hosting News 2012-11-07 15:06:36
10-14-2012 Roswell, NM - The Hosting Shift Blog 2012-10-24 15:14:40


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes
Postbit Selector

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Forum Jump
Login:
Log in with your username and password
Username:
Password:



Forgot Password?
Advertisement:
Web Hosting News:



 

X

Welcome to WebHostingTalk.com

Create your username to jump into the discussion!

WebHostingTalk.com is the largest, most influentual web hosting community on the Internet. Join us by filling in the form below.


(4 digit year)

Already a member?