Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80700
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <23490588-0131-4B0F-A7AA-C9C8C766626C@ajf.me>
References: <CA+kxMuQcfMY00k+WtnNUppD7N9PMQsx356h1XTy1X8px1m0MBw@mail.gmail.com>
	<003201d0326b$6fd27f60$4f777e20$@tekwire.net>
	<23490588-0131-4B0F-A7AA-C9C8C766626C@ajf.me>
Date: Sat, 17 Jan 2015 16:04:01 +0000
Message-ID: <CALKiJKqsUPDN23c7DrpQrhXJD-RU1W4ZNq1h0Lotgrcm+JgUKA@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: francois@tekwire.net, Dan Ackroyd <danack@basereality.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1133fa76d42b5f050cdb3c56
Subject: Re: [PHP-DEV] Class constructor behaviour
From: rowan.collins@gmail.com (Rowan Collins)

--001a1133fa76d42b5f050cdb3c56
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 17 January 2015 at 15:43, Andrea Faulds <ajf@ajf.me> wrote:

> Hi Fran=C3=A7ois,
>
> > On 17 Jan 2015, at 15:37, Fran=C3=A7ois Laupretre <francois@tekwire.net=
>
> wrote:
> >
> > 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.
> >
> > This is more compatible with the 'exception-less' behavior of the core
> in general. The constructor is still free to throw an exception but this
> wouldn't be encouraged nor the standard way to inform the core that an
> error occurred.
>
> I don=E2=80=99t really agree here. For some reason we have this tradition=
 of not
> using exceptions for =E2=80=9Cprocedural=E2=80=9D stuff. That sort of mak=
es sense for
> functions, but classes are =E2=80=9COOP=E2=80=9D and therefore I don=E2=
=80=99t see a good reason
> why they shouldn=E2=80=99t throw exceptions. Exceptions and OOP (and name=
spaces,
> even) should not be the domain of userland exclusively, they are also the
> domain of internals/core. If you really hate exceptions, I=E2=80=99d say =
you should
> just use one of those ridiculous =E2=80=9Cprocedural=E2=80=9D alternative=
 functions (that
> are just methods in disguise) that we went to the bother of adding.
>
> By the way, it irks me (and many others) that PDO doesn=E2=80=99t throw e=
xceptions
> by default. It really ought to, it=E2=80=99s an OOP API, I=E2=80=99d love=
 to see that
> changed in PHP 7.
>
>
The difference is that AFAIK all the exceptions returned by OOP extensions
right now are of classes specific to that extension, whereas this would be
a global engine-thrown exception. We'd have to decide on the class of the
exception, its position in a class hierarchy, etc. I'm personally in favour
of the core using exceptions more, but only if done properly (I don't like
the idea of a single non-semantic EngineException as previously proposed,
except as the base class for a proper hierarchy).

I'm also in favour of extension objects behaving more like userland ones,
which means that a constructor should either give an instance of the named
class or error (if you need something more flexible, build a factory
instead). If extensions want to throw their own exceptions from
constructors, that's fine, obviously, but it would be more consistent right
now if the generic "extension failed to create the right thing" catch
issued an error like for other "unexpected condition" scenarios.

--=20
Rowan Collins
[IMSoP]

--001a1133fa76d42b5f050cdb3c56--