Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:21474
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <F7.19.29075.9CCE4C34@pb1.pair.com>
To: internals@lists.php.net
Date: Wed, 11 Jan 2006 22:32:13 +1100
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
References: <200601101613.02531.thiago.silva@kdemail.net> <43C40D11.6020001@zend.com>
In-Reply-To: <43C40D11.6020001@zend.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PATCH] entry #35269
From: t.starling@physics.unimelb.edu.au (Tim Starling)

Antony Dovgal wrote:
> On 10.01.2006 19:13, Thiago Silva wrote:
> 
>> Hi,
>> can anyone review this?
>>
>> It's a one-line patch for the silent operator (@), wich currently
>> supress fatal error messages (undesirable for "@include" pehaps, wich
>> makes difficult for debugging scripts).
> 
> 
> With this patch you basically change whole @ functionality, thus
> breaking both BC and expected behavior in the same time.
> And even in the case with include() - this is _expected_. If you don't
> want to see all error messages silenced, just use set_error_reporting()
> to set desired error level.

Suppression of fatals is an irritating misfeature. There's nothing worse
than trying to work out where in tens of thousands of lines of code some
idiot developer put an @ before a function invocation where the function is
only available on some systems. In MediaWiki we use wfSuppressWarnings() and
wfRestoreWarnings() instead of @, but of course that's slower to type and to
execute, so the temptation is always there to use the evil @.

If suppression of fatals could be switched off, even as an INI setting off
by default, it would be a great help to developers.

-- Tim Starling