Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84128
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.178 as permitted sender)
Message-ID: <54F38D29.9080007@gmail.com>
Date: Sun, 01 Mar 2015 14:05:29 -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>, 
 "internals@lists.php.net" <internals@lists.php.net>
References: <CA+kxMuQP76wjEAx8U1JL=VLi-mdrmEwfX_0DDqDibTHZwpqDyg@mail.gmail.com>
In-Reply-To: <CA+kxMuQP76wjEAx8U1JL=VLi-mdrmEwfX_0DDqDibTHZwpqDyg@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!

> 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.

-- 
Stas Malyshev
smalyshev@gmail.com