Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84134
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain basereality.com from 209.85.160.180 cause and error)
MIME-Version: 1.0
In-Reply-To: <54F38D29.9080007@gmail.com>
References: <CA+kxMuQP76wjEAx8U1JL=VLi-mdrmEwfX_0DDqDibTHZwpqDyg@mail.gmail.com>
	<54F38D29.9080007@gmail.com>
Date: Sun, 1 Mar 2015 23:32:09 +0000
Message-ID: <CA+kxMuRetTATAoO25fU+d78Vza909-YcQFJp2784jQMTCsq-sA@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Constructor behaviour of internal classes
From: danack@basereality.com (Dan Ackroyd)

On 1 March 2015 at 22:05, Stanislav Malyshev <smalyshev@gmail.com> wrote:

> I'm not sure why this RFC assumes the exception is much better than
> returning null.
>
> It is a long standing tradition in PHP that operations that can be
> expected to fail - like fopen()..  do not produce
> fatal errors but instead return error values which can be checked for
> and handled.

The difference is that fopen can fail even if passed parameters that
are correct e.g. due to file permission problems. Because of that the
failure is not exceptional and so needs to be checked. Having to do
this through exceptions would be annoying which is why people prefer
to use procedural function for handling files, even when OO style
interfaces are available.

When a user calls `new NumberFormatter()` they can know ahead of time
whether the parameters are valid or not. Any call with valid
parameters will succeed. Calls with invalid parameters will fail.
Because the programmer should only be passing in valid paramters any
failure is by it's nature an unexpected error.

And to be precise, fopen does not return error values. It returns a
single error value of false. There is no indication of why the error
occurred. Exceptions allow a message to be attached saying what went
wrong, which is why they are preferred in a lot of cases.

> 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.

You are one of the very few people who don't like exceptions. I
completely agree exceptions shouldn't be used everywhere and that they
should be used only for exception circumstances. But the vast majority
of PHP programmers are completely used to them.

If you don't see the benefits of using exceptions in some cases by
now, it's very unlikely that any argument is going to persuade you of
how they can be used (judiciously) to write clean code.

Luckily, this RFC isn't a general discussion about error handling, it
is specifically about the behaviour of internal classes being
'special' either by having behaviour which is not possible for
userland classes to do, or just being unusable after being
instantiated due to incorrect parameters.

cheers
Dan