Re: Exceptions for method on non-object rather than fatal (desired feature?)

From: Date: Wed, 22 Feb 2012 19:30:56 +0000
Subject: Re: Exceptions for method on non-object rather than fatal (desired feature?)
References: 1 2 3 4 5 6 7 8 9  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message 
Hi,

Am 22.02.2012 20:04, schrieb Larry Garfield:

On 2/22/12 12:37 PM, Peter Lind wrote:


I would also support this. There's a myriad reasons why something may

return NULL or FALSE when you expect it to return an object, some of them
even legitimate. Any function/method whose documentation line is "returns
the foo object, or NULL if someone screwed up and there isn't one" is
perfectly reasonable in many cases, IMO, but makes all chains a potential
fatal. An exception would make a lot more sense, and allow us to
centralize handling of such "exceptional" cases rather than throwing
if-checks everywhere. (Which is exactly what exceptions are for.)


--Larry Garfield


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



Seems to me this change would encourage bad habits (breaking the law of
Demeter) which would personally put me against it.

Regards
Peter


How? What bad habit does this encourage?


The law of demeter (as mentioned). In short: Always interact with your direct neighbours only keeps the dependencies always obvious (or something like this). As a side effect you'll not see such chains, if you follow this rule.

In my opinion calling a method on "null" sounds like a bug. If you want to chain method calls _ensure_ they _always_ returns an object of the expected type, or (if null is intended) test the object first. Looks uglier, but thats the price of return values of different types.

What should happen, when an object is returned, but it an instance of another class? Or on string?



--Larry Garfield

Thread (18 messages)

« previous php.internals (#57959) next »