Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62010
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 64.22.89.134 as permitted sender)
Message-ID: <501BF3B7.9020304@ajf.me>
Date: Fri, 03 Aug 2012 16:52:23 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Ferenc Kovacs <tyra3l@gmail.com>
CC: Stan Vass <sv_forums@fmethod.com>, Leigh <leight@gmail.com>, 
 internals@lists.php.net
References: <CAPwsocF=bHLo6CH4iL-7QPsYkLOyB0cA6HHjLHLVHxuQayOmxw@mail.gmail.com> <3F2B7A4F937D4FA9A1CE88818CBCEB1D@pc> <CAH-PCH7Hc2O+GFvQWNQ37LKy4LcR7NVhEGCE+aAPH9USufjdvQ@mail.gmail.com>
In-Reply-To: <CAH-PCH7Hc2O+GFvQWNQ37LKy4LcR7NVhEGCE+aAPH9USufjdvQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Why do disabled functions / classes generate a WARNING.
From: ajf@ajf.me (Andrew Faulds)

On 03/08/12 16:50, Ferenc Kovacs wrote:
> 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 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().
>>
>>
> 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.
>
Warnings are special, they aren't really errors as such. They wouldn't 
become exceptions.

Also, why should an erroring function return a value?

-- 
Andrew Faulds
http://ajf.me/