Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84454
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.172 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, 9 Mar 2015 13:52:07 +0900
Message-ID: <CAGa2bXacijMKdqeCUy6ov-8Mdgh3SVvH8uKHOd0Fd_h03GUd7w@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=001a1135e1ea3b916d0510d3ce1f
Subject: Re: [PHP-DEV] [RFC][DISCUSSION] Constructor behaviour of internal classes
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a1135e1ea3b916d0510d3ce1f
Content-Type: text/plain; charset=UTF-8

Hi Stas,

On Mon, Mar 2, 2015 at 7:05 AM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> > 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 come up with better idea for both procedural and OO style error handling.
The other day, I wrote simple PostgreSQL and MongoDB benchmark
script to see how PostgreSQL outperforms MongoDB.
(PostgreSQL 9.4 is about 30% faster than MongoDB 2.6, BTW)

https://gist.github.com/yohgaki/a11a2f435f3d8f6ee096

For this kind of simple procedural code, exceptions are useless or even
harmful. If there is a RFC that ignores unhandled exceptions, no try block
and no default exception handler then ignore exception, I'll vote "yes" for
it.
Having this kind of switch would be great for procedural code and OO API
designers.

Just an idea.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a1135e1ea3b916d0510d3ce1f--