On Fri, Aug 6, 2010 at 5:16 PM, Platonides <Platonides(a)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