On Fri, Aug 6, 2010 at 5:16 PM, Platonides Platonides@gmail.com wrote:
The point is, both of them are suppressed by wfSuppressWarnings... So what can the @ be suppressed that wfSuppressWarnings may have missed?
Unless the decision to add an @ there predates out own warning supppresion.
@ must not be used, ever. Any uses you see are wrong and should be refactored. The vast majority of offenders are lazy array index accessing:
BAD PROGRAMMER: $foo = @$bar['key'];
GOOD PROGRAMMER: $foo = isset( $bar['key'] ) ? $bar['key'] : null;
It's a few extra keystrokes, but you're saved from using the @ to suppress *all* errors that could be occurring there--not just the possible index-does-not-exist. Better example:
$foo = @$this->obj->bar['key'];
If you use @, you're also suppressing that $obj might not be an object, or that $bar doesn't have a key 'key'. Another common pitfall might be:
@$obj->method();
What happens if method() changes and nobody checked the callers? You're now possibly suppressing errors you never meant to suppress.
What sort of errors are ok to suppress, and how do I do it? The most common (and annoying) errors that need suppression are file operation things (fopen, file_get_contents, etc), usually due to invalid permissions. If you want to hide errors here, it's ok to do something like:
wfSuppressWarnings(); $t = file_get_contents( 'somefile' ); wfRestoreWarnings();
This will properly suppress and restore the warnings for you. Handy trick, if you're making directories, wfMkdirParents() handles all of this for you, so you can just check the boolean return without having to worry about possible errors.
-Chad