Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62009
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <3F2B7A4F937D4FA9A1CE88818CBCEB1D@pc>
References: <CAPwsocF=bHLo6CH4iL-7QPsYkLOyB0cA6HHjLHLVHxuQayOmxw@mail.gmail.com>
	<3F2B7A4F937D4FA9A1CE88818CBCEB1D@pc>
Date: Fri, 3 Aug 2012 17:50:20 +0200
Message-ID: <CAH-PCH7Hc2O+GFvQWNQ37LKy4LcR7NVhEGCE+aAPH9USufjdvQ@mail.gmail.com>
To: Stan Vass <sv_forums@fmethod.com>
Cc: Leigh <leight@gmail.com>, internals@lists.php.net
Content-Type: multipart/alternative; boundary=047d7b6d7bec3ff60f04c65e7c72
Subject: Re: [PHP-DEV] Why do disabled functions / classes generate a WARNING.
From: tyra3l@gmail.com (Ferenc Kovacs)

--047d7b6d7bec3ff60f04c65e7c72
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 3, 2012 at 4:19 PM, Stan Vass <sv_forums@fmethod.com> wrote:

> 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 th=
e
> 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 brea=
k
> BC and require a major rethinking of the way PHP issues errors.
>
> See: set_error_handler().
>
>
a php function/operation can raise more than one warning, how would you
handle that?
with exceptions you would only get the first one.
another issue is that with the current error handling model a call can
trigger a non-fatal error and still return some data.
with exeptions you can't do that.
so changing our internal error handling isn't as easy to start throwing
ErrorException-s, it would require much more workthan that.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--047d7b6d7bec3ff60f04c65e7c72--