Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80714
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <003201d0326b$6fd27f60$4f777e20$@tekwire.net>
References: <CA+kxMuQcfMY00k+WtnNUppD7N9PMQsx356h1XTy1X8px1m0MBw@mail.gmail.com>
 <003201d0326b$6fd27f60$4f777e20$@tekwire.net>
Date: Sun, 18 Jan 2015 02:50:20 +0100
Message-ID: <CADyq6sJZ2-_Sqo93uf9Q2qTqFPLMQMu0=_MBQMiygK1-wArGJg@mail.gmail.com>
To: francois@tekwire.net
Cc: Dan Ackroyd <danack@basereality.com>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bea39f4da966b050ce36e12
Subject: Re: [PHP-DEV] Class constructor behaviour
From: ocramius@gmail.com (Marco Pivetta)

--047d7bea39f4da966b050ce36e12
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 17 January 2015 at 16:37, Fran=C3=A7ois Laupretre <francois@tekwire.net>
wrote:

> > De : Dan Ackroyd [mailto:danack@basereality.com]
> >
> > This is pretty horrible and should be fixed by making sure that
> > constructors either return an object or throw an exception.
> > Additionally the exception policy for core (that was previously
> > discussed here: http://marc.info/?t=3D119263748000001&r=3D1&w=3D2 ) sho=
uld
> > be updated so that any constructor returning NULL is considered a bug,
> > no matter what the ini settings are.
>
> I would prefer deciding that returning null is the standard way for a
> constructor to inform the PHP core that the object creation failed (for a=
ny
> reason). This would be trapped by the core and cause a catchable fatal
> error.
>

A constructor that fails is a hard failure (factory method failed to
produce the expected value), and is an exceptional case that can or cannot
be handled (via catch).
It's not just a failed operation (expected to eventually fail), but
something really went wrong, badly.

An exception fits perfectly in this case.

Additionally, it makes no sense to have inconsistent behavior between
internal classes and userland classes: it is currently impossible for a
userland class to have the `new` operator producing an object that is not
an instance of the class after that operator.

It feels weird, from a user perspective, to have `new` producing non-object
values.

The general feeling when dealing with cases such as PDO's constructor is
"WAT?!".

Therefore gogogo Danack!

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--047d7bea39f4da966b050ce36e12--