On Mon, February 27, 2012 2:08 pm, Johannes Schlüter wrote:
> On Mon, 2012-02-27 at 21:05 +0100, Gustavo Lopes wrote:
>> On Mon, 27 Feb 2012 20:09:08 +0100, Johannes Schlüter
>> <johan...@schlueters.de> wrote:
>>
>> > On Mon, 2012-02-27 at 13:05 -0600, Richard Lynch wrote:
>> >>
>> >> I'd have to come up with some OTHER scenario not involving fatal
>> >> error, such as:
>> >>
>> >> strict $db = new DB();
>> >
>> > The example is wrong. The new operator will always return an
>> instance of
>> > the given class (or there will be an exception).
>> > [...]
>>
>>
>> This is not true. The new operator can return NULL. In fact, the
>> intl
>> extension uses this extensively:
>
> ok, internal stuff can do everything it wants. But it shouldn't. Doing
> that is really bad and I wasn't aware of that case. :-)
>
> And since it's bad another example should be used :-)

At the risk of quoting the docs to a guy who probably wrote a bunch of
it...

http://www.php.net/manual/en/language.oop5.basic.php#language.oop5.basic.new

doesn't really SAY you can't return NULL in the event of an Exception
or raising an error...

Maybe it's a documentation error to not explicitly state what the
return value is when one raises an error and/or throws the Exception.

But it may not even make sense to create an Object of that type, or
could be incredibly difficult to create if there are enough "extends",
"interface" and whatnot...

So "shouldn't" is an un-documented statement, at this time, and more a
"Best Practice" perhaps. :-)

To me, however, returning NULL seems like a reasonable action when the
spec is followed and an Exception is thrown or an error is raised.

-- 
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to