Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61177
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.143 as permitted sender)
Message-ID: <4FFF0717.6050703@sugarcrm.com>
Date: Thu, 12 Jul 2012 10:19:19 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: Rasmus Lerdorf <rasmus@lerdorf.com>
CC: Anthony Ferrara <ircmaxell@gmail.com>, 
 "internals@lists.php.net" <internals@lists.php.net>
References: <CAAyV7nGwONAwPRRYLKswJtR-1RsrhQc5yS+dVuyZr1BHBW_NBA@mail.gmail.com> <4FFEFBB3.7090507@sugarcrm.com> <4FFEFD81.6020404@lerdorf.com> <4FFEFF71.2060202@sugarcrm.com> <4FFF0584.6080708@lerdorf.com>
In-Reply-To: <4FFF0584.6080708@lerdorf.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Iterable Type Hint
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> This gives quite a bit more info since we now know that it was an
> argument and specifically which argument it was, what its type was and
> what it should have been vs. having a fatal from somewhere deep in the
> function itself. So I disagree with you on it not making life easier for
> the caller in this specific case where there is no way for the type to
> be coerced into something that makes sense.

You've traded bad error message for slightly better error message, but
on the way you've lost the ability to actually handle this situation.
Which exactly what bothers me - we're teaching people that the right way
of handling any unexpected situation is to rely on post-mortem error
logging after it blows up in runtime. I'm not sure it's such a good idea.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227