Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73841
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain thomasbley.de from 85.13.137.24 cause and error)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: ALL-INKL Webmail 2.11
In-Reply-To: <alpine.DEB.2.10.1404290922560.4404@whisky.home.derickrethans.nl>
References: <1005082480.406481.1398600039315.open-xchange@email.1und1.de><alpine.DEB.2.10.1404290922560.4404@whisky.home.derickrethans.nl>
To: php@thekid.de, derick@php.net
Cc: internals@lists.php.net
Message-ID: <20140429084608.4131726006D@dd15934.kasserver.com>
Date: Tue, 29 Apr 2014 10:46:08 +0200 (CEST)
Subject: Re: [PHP-DEV] RFC: Catchable "call to a member function of a non-object"
From: mails@thomasbley.de

Derick Rethans wrote on 29.04.2014 10:26:

> On Sun, 27 Apr 2014, php@thekid.de wrote:
> 
>> Hello everyone,
>> 
>> as per the RFC process I'd like to start a discussion on the RFC
>> I've put up on the RFC Wiki:
>> 
>>   https://wiki.php.net/rfc/catchable-call-to-member-of-non-object
>>   RFC: Catchable "call to a member function of a non-object", 1.0
>> 
>> The essence of this pull request is that it converts this fatal error
>> into E_RECOVERABLE_ERRORs. Framework authors may choose to convert
>> these into exceptions, as they already do with argument type mismatches.
>> 
>> Feedback is welcome!
> 
> Besides the technical issues that Johannes already mentions, I am also 
> against this for logic reasons.
> 
> Calling methods on NULL objects is a programming mistake. You either 
> have a bug in the code that creates the objects, and in cases where it 
> is somethings OK to not have an object, you forgot to check whether you 
> have an objects. Programming mistakes should not be hidden by error 
> handlers.


Hello Derick,

the RFC is not about hiding programming mistakes, it is still possible to return false in the error handler.
Btw. PHP tolerates a lot of programming mistakes, see Warning, Notice and that's why we like PHP.
In most cases (like concurrent deletes), additional checks take a lot of time for implementation and testing and in most cases, the code is never executed.
There are many functions (like mysqli::query, mysqli::prepare) that return false|null|object. Covering everything with if(...) makes the code bigger and less readable.

Regards,
Thomas