Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84150
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.169 as permitted sender)
Sender: Michael Wallner <mike.php.net@gmail.com>
Message-ID: <54F417E1.8010703@php.net>
Date: Mon, 02 Mar 2015 08:57:21 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Stanislav Malyshev <smalyshev@gmail.com>, 
 Dan Ackroyd <danack@basereality.com>,
 "internals@lists.php.net" <internals@lists.php.net>
References: <CA+kxMuQP76wjEAx8U1JL=VLi-mdrmEwfX_0DDqDibTHZwpqDyg@mail.gmail.com> <54F38D29.9080007@gmail.com>
In-Reply-To: <54F38D29.9080007@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Constructor behaviour of internal
 classes
From: mike@php.net (Michael Wallner)

On 01/03/15 23:05, Stanislav Malyshev wrote:
> Hi!
> 
>> This email is to announce the formal opening of discussion for an RFC
>> to clean up the behaviour of the constructors shown by several
>> internal classes.
>>
>> https://wiki.php.net/rfc/internal_constructor_behaviour
> 
> I'm not sure why this RFC assumes the exception is much better than
> returning null. Exceptions are harder to handle (requires separate
> syntax construct) and they are more expensive at runtime (must create an
> object, collect the backtrace, etc.). Also, not catching the exception
> immediately usually will lead to a complete application failure (usually
> with an obscure error message like "internal operation failed", since
> displaying raw exceptions to the user can be unsafe) instead of
> finer-grained handling.
> It is a long standing tradition in PHP that operations that can be
> expected to fail - like fopen(), date_create(), etc. - do not produce
> fatal errors but instead return error values which can be checked for
> and handled. It is true that some SPL classes departed from that, but
> this IMO was not an improvement but rather an annoyance that each time
> you use an SPL thing you have to write it in a try/catch block. That
> leads to much more boilerplate code than necessary.
> 
> Now I understand that PHP model of doing things may be unusual for some
> people that come from other language background where everything throws
> exceptions for any slightest reason and there's no other means of error
> checking. But I think we can do better rather than that and have more
> flexible error handling - even if it would require people to be
> introduced to a concept they were not familiar with before coming to
> PHP, such as not using exceptions for everything.
> 

I'm not sure I can understand your crusade against this topic.

Consistency with userland is beneficial, because the majority of PHP
developers probably do not expect `new` to yield anything than a
concrete instance or an exception.

Quoting php.net/manual:

	To create an instance of a class, the new keyword must be used. An
object will *always* be created *unless* the object has a constructor
defined that *throws an exception on error*.

Emphasis mine.

Do you know of any other case where a `new` operator in an object
oriented context can return NULL, except C++ where you have to
explicitely ask for that behavior?

-- 
Regards,
Mike