Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84151
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
Message-ID: <54F41E71.1020703@lsces.co.uk>
Date: Mon, 02 Mar 2015 08:25:21 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: 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> <54F3E2D0.9060203@gmail.com>
In-Reply-To: <54F3E2D0.9060203@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: lester@lsces.co.uk (Lester Caine)

On 02/03/15 04:10, Stanislav Malyshev wrote:
>> 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.

If an object can not be created then the handle should be null. That is
all that is needed. It's no different to a result being an empty string.
If one is catering for the fact that there is no result then it's not an
exception and we either handle the empty result or just carry on.
Nothing here has any bearing on 'modular programming' it is all
perfectly well handled.

>> > 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).

Simply follows on from above. If we need to know why there was no object
created we ask ... if we have no need to know AT THIS STAGE we would
have to handle the exception to get back to the normal flow?

>> > 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.

Exceptions are perfectly valid when the work flow has to be interrupted
for something that can't be catered for in the normal flow. 'Engine'
exceptions due to lack of resources and trying to execute something when
the object was not created. There are certainly 'exceptions in the
engine' where catch would be helpful and perhaps avoid the number of
white screens I currently see, but I feel that THAT particular RFC may
open the door for more general 'exception' switches?

>> > 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.

Seconded ... that people try to work in ways they are used to rather
than in ways that are operationally more efficient is the problem. Just
as many 'older' PHP users are more used to a different style of
'modularity'. It's not wrong and it may be that better education is what
is missing ... both ways.

>> > 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.

We can agree that any process that can create a handle to an object
which can't actually function as requested then it is an error that
needs fixing. Some of the shortcoming of PDO may well be candidates for
an exception, but that is only because they don't follow the rules used
for other database extensions. Similarly a number of the other packages
you have identified need similar shortcoming fixed, but FIXED rather
than simply now adding an exception to hide the poor modularity of the
package!

The 'correct' work flow question should be "Can I correct the error in
the parameters passed?" If the answer to this is yes, then the object
should at least be in a stable state to allow that. If there is no
object, perhaps because a file does not exist, then the work flow may
already define the next step ... create the file ... then if that does
not work one may bow out with a null object, or leave an object with a
valid handle but with a state showing why it's an empty object.

The only package I use on the list is PDO, and where that returns 'null'
is totally the correct result. I can see where this is also perfectly
correct for some of the other situations as well. The Reflection stuff
is something I have yet to find an use for ... a decent IDE is still the
right place to do most of that ... but your examples are areas where the
other RFC comes into play anyway.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk