Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84142
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.51 as permitted sender)
Message-ID: <54F3E2D0.9060203@gmail.com>
Date: Sun, 01 Mar 2015 20:10:56 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Dan Ackroyd <danack@basereality.com>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <CA+kxMuQP76wjEAx8U1JL=VLi-mdrmEwfX_0DDqDibTHZwpqDyg@mail.gmail.com>	<54F38D29.9080007@gmail.com> <CA+kxMuRetTATAoO25fU+d78Vza909-YcQFJp2784jQMTCsq-sA@mail.gmail.com>
In-Reply-To: <CA+kxMuRetTATAoO25fU+d78Vza909-YcQFJp2784jQMTCsq-sA@mail.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: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> 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

Failure of the formatter on wrong format or data is of the same kind -
its not exceptional and only caused by input data that could be right
but in this circumstance aren't.

> When a user calls `new NumberFormatter()` they can know ahead of time
> whether the parameters are valid or not. Any call with valid

I certainly don't see how this can be true. The code can receive
generated format and user-supplied locale (e.g. loaded from resource
files and HTTP headers) and the developer can have no idea if it's
correct or not. Exactly the same as with files or date_create().

> Because the programmer should only be passing in valid paramters any
> failure is by it's nature an unexpected error.

That's exactly like saying programmer should only try to open existing
files so any failure by its nature is an unexpected error. You are
trying to create a difference when there's none. But if you don't like
fopen() there are many other factory functions that behave the same -
like date_create() or simplexml_load_string(). You can claim that all
these failures are somehow "not exceptional" and only date formatting
using NumberFormatter is somehow "exceptional" but that doesn't sound
very logical to me.

> 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.

This is not relevant since error information can be retrieved by other
methods, and intl has such facility (as do other APIs, most of the APIs
have facilities to retrieve error information and very rarely they rely
on exceptions for that - exceptions are not very good means of doing that).

> You are one of the very few people who don't like exceptions. I

Who said I don't like exceptions? I like exceptions, I adore, cherish
and admire them - when they are used appropriately. What I am saying is
not that exceptions are universally bad - but they are also not
universally good, they should be used sparingly, in appropriate places,
and not every situation where something is not going as planned should
necessarily be an exception.

> should be used only for exception circumstances. But the vast majority
> of PHP programmers are completely used to them.

They can not be used to them in the context of this RFC since PHP never
had them in such context. They can be used to them in different
contexts, but I've also seen a lot of boilerplate code and unclear error
reporting growing from the fact that some code is too exception-happy.

> 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.

If something is unusable after being instantiated, it would better just
let the user handle it instead of producing bad object. I agree with
that - if you produce an object, it should be useful, otherwise no point
in it. However, I disagree with the other part.

-- 
Stas Malyshev
smalyshev@gmail.com