Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84131
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.169 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <54F38D29.9080007@gmail.com>
References: <CA+kxMuQP76wjEAx8U1JL=VLi-mdrmEwfX_0DDqDibTHZwpqDyg@mail.gmail.com>
 <54F38D29.9080007@gmail.com>
Date: Mon, 2 Mar 2015 07:36:33 +0900
Message-ID: <CAGa2bXYo_itR778+_qY0wGbrPV541Cr5JL5SOib5B1fEbTwsCg@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Dan Ackroyd <danack@basereality.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1135a5142e3a6b051041bebf
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Constructor behaviour of internal classes
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a1135a5142e3a6b051041bebf
Content-Type: text/plain; charset=UTF-8

Hi Stas,

On Mon, Mar 2, 2015 at 7:05 AM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> > This email is to announce the formal opening of discussion for an RFC
> > to clean up the behaviour of the constructors shown by several
> > internal classes.
> >
> > https://wiki.php.net/rfc/internal_constructor_behaviour
>
> I'm not sure why this RFC assumes the exception is much better than
> returning null. Exceptions are harder to handle (requires separate
> syntax construct) and they are more expensive at runtime (must create an
> object, collect the backtrace, etc.). Also, not catching the exception
> immediately usually will lead to a complete application failure (usually
> with an obscure error message like "internal operation failed", since
> displaying raw exceptions to the user can be unsafe) instead of
> finer-grained handling.
> It is a long standing tradition in PHP that operations that can be
> expected to fail - like fopen(), date_create(), etc. - do not produce
> fatal errors but instead return error values which can be checked for
> and handled. It is true that some SPL classes departed from that, but
> this IMO was not an improvement but rather an annoyance that each time
> you use an SPL thing you have to write it in a try/catch block. That
> leads to much more boilerplate code than necessary.
>
> Now I understand that PHP model of doing things may be unusual for some
> people that come from other language background where everything throws
> exceptions for any slightest reason and there's no other means of error
> checking. 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.


I can understand your argument. It works.

This proposal is about code modularization. Software engineering is
a history of better modularization.

 - Structured programming
 - Object Oriented programming
 - AOP
 - DbC

Exception is one of them.

While error handling without exception works, it decreases modularization.
Therefore, it decreases maintainability and increases chance of bugs.

Besides modularization, consistency is important for programming language
also.

These are the topic/objective for this RFC. IMHO.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a1135a5142e3a6b051041bebf--