Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80743
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <A3.E9.18613.7F89BB45@pb1.pair.com>
References: <CA+kxMuQcfMY00k+WtnNUppD7N9PMQsx356h1XTy1X8px1m0MBw@mail.gmail.com>
	<003201d0326b$6fd27f60$4f777e20$@tekwire.net>
	<23490588-0131-4B0F-A7AA-C9C8C766626C@ajf.me>
	<A3.E9.18613.7F89BB45@pb1.pair.com>
Date: Sun, 18 Jan 2015 15:42:04 +0000
Message-ID: <CALKiJKqpk7X0yn0d_PWOKU1S7m156dF7865aLCP5dLF=q39uWg@mail.gmail.com>
To: Tony Marston <TonyMarston@hotmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c25f72328f60050cef0ca4
Subject: Re: [PHP-DEV] Class constructor behaviour
From: rowan.collins@gmail.com (Rowan Collins)

--001a11c25f72328f60050cef0ca4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 18 January 2015 at 11:28, Tony Marston <TonyMarston@hotmail.com> wrote:

> "Andrea Faulds"  wrote in message news:23490588-0131-4B0F-A7AA-
> C9C8C766626C@ajf.me...
>
>>
>> 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=
 any
>>> 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 thi=
s
>>> 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 traditio=
n of not
>> using exceptions for =E2=80=9Cprocedural=E2=80=9D stuff. That sort of ma=
kes 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.
>>
>
> You are forgetting one minor thing - an object may be instantiated from a
> piece of procedural code. In fact the very first object can only be
> instantiated from procedural code.


I'm not sure what you mean by the second sentence here; which is the "very
first object"?



> The idea that every piece of code that uses "new" will have to be amended
> to be in a try...catch block is a huge amount of work that does not solve
> any problem (except to satisfy the delicate sensibilities of the OO
> purists).



Bear in mind that there are costs to users writing new code as well as
costs to those maintaining existing ones. When writing code from scratch,
it's actually much easier to write code with catch/finally than to check
for non-object returns before using every object. The errors for uncaught
exceptions are generally much easier for a new user to understand than the
errors for accessing a method on what turns out to be a null value not an
object.



>
>
>  Exceptions and OOP (and namespaces, 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 method=
s in disguise) that
>> we went to the bother of adding.
>>
>
> If you really want a clever way of introducing exceptions into PHP withou=
t
> breaking huge amounts of existing code then how about this idea - change
> the language to detect if a function/method is being called within a
> try...catch block or not. If it is then throw an exception, but if it is
> not then use the old error handler. In this way the use of exceptions wou=
ld
> not be forced on the developer and existing code would not break. This
> would me more work for the core developers, but no broken code in userlan=
d.
>
>
Unfortunately, that wouldn't be as useful as it sounds. Consider this code:

try { somefunc($foo); }
catch ( InvalidArgumentException $e ) { ... }

If somefunc() internally uses PDO, should it automatically switch to
exception-throwing mode, because a try-block is in the stack? Or should it
hunt in advance for matching catch() clauses, which would probably be
extremely slow? And if the user lazily writes catch(Exception $e) around a
top-level function, suddenly their whole application behaves differently,
because their inline error handling suddenly stops working?

Unfortunately, exceptions require a specific way of thinking, at least in
the area of code where they occur, because they don't neatly reduce to
equivalent linear code.

--=20
Rowan Collins
[IMSoP]

--001a11c25f72328f60050cef0ca4--