@ before functions name

[ReVeR]

Hello
What does @ b4 function name do when the function is called.
Thx

[AndyB]

suppresses errors - so it's not usually a good idea

[play_]

[!--quoteo(post=380555:date=Jun 6 2006, 07:32 AM:name=AndyB)--][div class=\'quotetop\']QUOTE(AndyB @ Jun 6 2006, 07:32 AM) [snapback]380555[/snapback][/div][div class=\'quotemain\'][!--quotec--]
suppresses errors - so it's not usually a good idea
[/quote]

But it also hides warnings. So it can be pretty useful

[AndyB]

[!--quoteo(post=380556:date=Jun 6 2006, 07:34 AM:name=play_)--][div class=\'quotetop\']QUOTE(play_ @ Jun 6 2006, 07:34 AM) [snapback]380556[/snapback][/div][div class=\'quotemain\'][!--quotec--]
But it also hides warnings. So it can be pretty useful
[/quote]
Good point. But I wouldn't use it while [i] developing[/i] a piece of code (when we all need all the help we can get back from error reporting and warnings).

[play_]

[!--quoteo(post=380562:date=Jun 6 2006, 07:56 AM:name=AndyB)--][div class=\'quotetop\']QUOTE(AndyB @ Jun 6 2006, 07:56 AM) [snapback]380562[/snapback][/div][div class=\'quotemain\'][!--quotec--]
Good point. But I wouldn't use it while [i] developing[/i] a piece of code (when we all need all the help we can get back from error reporting and warnings).
[/quote]


That's true.

[kenrbnsn]

[!--quoteo--][div class=\'quotetop\']QUOTE[/div][div class=\'quotemain\'][!--quotec--]But it also hides warnings.[/quote]
That's what [b]AndyB[/b] said. I would recommend you do not use it while debugging your code.

I use it only in situations where I know I will get an error that I want to ignore. For example, if I use the mail fumction -- when I'm write and testing on my laptop, I know the mail function will give me an error because I haven't set it up in the PHP.INI file for the PC. So I don't want to see the error everytime -- yes I can wrap the code in an "if" statement to test whether I'm on the PC, but I took the "easy" way out. [img src=\"style_emoticons/[#EMO_DIR#]/smile.gif\" style=\"vertical-align:middle\" emoid=\":smile:\" border=\"0\" alt=\"smile.gif\" /]

Ken

[Koobi]

I agree in saying that you should avoid supressing errors like this.

when developing, i would enable all error messages, even warnings and notices.

when publishing, it might be best to hide errors via error_reporting() and using an error handler to quitely inform you of the errors and displaying a custom predefined error message to the users of the web app/site.

and like kenrbnsn said, i would only use @ if absolutely necessary.



here's an example for using @ when including files:

[code]
<?php
    if(@!include 'config.php')
    {
        echo 'A required configuration file could not be included. Script terminating.';
        exit(0);
    }
?>
[/code]




IMO, when publishing the system, if you're handling the problem yourself, it's ok to hide them from everyone else...so long as person in charge (YOU) knows what's going on.

[obsidian]

[!--quoteo(post=380571:date=Jun 6 2006, 08:32 AM:name=Bane)--][div class=\'quotetop\']QUOTE(Bane @ Jun 6 2006, 08:32 AM) [snapback]380571[/snapback][/div][div class=\'quotemain\'][!--quotec--]
IMO, when publishing the system, if you're handling the problem yourself, it's ok to hide them from everyone else...so long as person in charge (YOU) knows what's going on.
[/quote]

to me, that's definitely the key. your code should be solid enough that you could leave the "@" off of every function in your application and never throw any warnings or errors (hypothetically). however, what happens when you have some portion of your app that allows for user input? there is no guard against [b]user error[/b], so in those cases, we've got to follow what bane suggests: account for the errors yourself. for instance, i have written a couple classes for a blog that allow many different types of user input, but if something is input improperly, an error may be thrown. in this case, rather than having the ugly PHP error thrown across the screen, i'd much rather catch the error myself and display it in a useful format. as such, i will use the @ symbol to suppress errors and run a check like bane shows above.

however, as i mentioned above, coding your application to run smoothly with error reporting set to "E_ALL" is a great practice anyway.

[poirot]

I tend to use '@' when some error may reveal sensitive information (like when I use flatfile databases, I always use @).

The bad thing is, it cannot be overridden by error_reporting(E_ALL), so I guess I'd be a better idea just to turn off error reporting...

[Koobi]

you can also use [a href=\"http://www.php.net/set_error_handler\" target=\"_blank\"]set_error_handler()[/a]. actually this is how it should be done. we shouldnt allow PHP to display its errors, we should be able to read PHP's message and display our own message to the viewer....what if your viewer doesn't speak english? If your system is not language dependant, you can use set_error_handler() and customize your message in their language.

oh and i'm quoting this from the above link (it's in the "Description"):
[!--quoteo--][div class=\'quotetop\']QUOTE[/div][div class=\'quotemain\'][!--quotec--]
It is important to remember that the standard PHP error handler is completely bypassed. error_reporting() settings will have no effect and your error handler will be called regardless - however you are still able to read the current value of error_reporting and act appropriately. [b]Of particular note is that this value will be 0 if the statement that caused the error was prepended by the @ error-control operator.[/b]
[/quote]



Another useful link in the PHP manual for the @ error operator:
[a href=\"http://www.php.net/manual/en/language.operators.errorcontrol.php\" target=\"_blank\"]Error Control Operators[/a]


i hope this dissuades you from using the @ operator where not necessary in the future :)