Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62005
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fmethod.com from 74.125.83.42 cause and error)
Message-ID: <3F2B7A4F937D4FA9A1CE88818CBCEB1D@pc>
To: "Leigh" <leight@gmail.com>,
	<internals@lists.php.net>
References: <CAPwsocF=bHLo6CH4iL-7QPsYkLOyB0cA6HHjLHLVHxuQayOmxw@mail.gmail.com>
Date: Fri, 3 Aug 2012 17:19:05 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Why do disabled functions / classes generate a WARNING.
From: sv_forums@fmethod.com ("Stan Vass")

> Hi all,
>
> Can anyone explain to me the reason that when a function or class is
> disabled via the ini setting, an attempt to access the disabled item
> generates a non-fatal error?
>
> I'm looking at a segfault in the SPL caused by the blind creation of a
> class, which seems to only fail when the class is disabled. I'm
> wondering in how many other places this could occur.
>
> The obvious solution is to be more careful and check return values,
> but a FATAL would also have prevented execution continuing.
>
> Thanks,
>
> Leigh.

PHP has a long history of issuing errors of the wrong type at the wrong 
time. My experience shows it's best to have an error handler convert all 
errors to catchable exceptions, with some error types (like E_STRICT, 
E_ERROR etc.) to become instant fatal errors (can't be caught).

This would also solve your use case since the warning will become an 
exception with a stack trace clearly pointing to the origin of your problem. 
Additionally you can handle an exception on a higher level in the stack once 
instead of doing it for every function/class call.

I'm afraid fixing the default behavior is a big hopeless since it'll break 
BC and require a major rethinking of the way PHP issues errors.

See: set_error_handler().

Stan