> -----Original Message----- > From: Peter Lind [mailto:peter.e.l...@gmail.com] > Sent: Wednesday, February 22, 2012 1:37 PM > To: Larry Garfield > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] Exceptions for method on non-object rather than fatal > (desired feature?) > > On Feb 22, 2012 7:05 PM, "Larry Garfield" <la...@garfieldtech.com> wrote: > > > > On 2/21/12 5:45 PM, Tjerk Meesters wrote: > >> > >> On 22 Feb, 2012, at 2:03 AM, Ralf Lang<l...@b1-systems.de> wrote: > >> > >>>>> I see no reason why it would be not desirable to have PHP raise > >>>>> the exception rather than putting more or less repeating code > >>>>> snippets all around the place. That is why I am asking. > >>>> > >>>> > >>>> You must be returning false/null somewhere. It's the same effor to > >>>> instead throw an exception or to return a Ghost family member. > >>> > >>> > >>> The $baby->mother() method cannot know if the using code just wants > >>> to > collect the $mother object or execute code on it. It can also not know if > having no $mother is a problem or just a fact to deal with. Unconditionally > raising an exception is a bit overkill here, at least if we would get an > exception for trying to access (null)->mother(); > >>> > >>> Currently the user code must check each link of the chain if it is available, although it is only interested if it can get the final result or not. > >>> > >>> I'll follow the suggestion and write an RFC. > >>> > >> > >> You'll have my vote! :) bloating code with chainable checks is just crazy, something that the engine can do much more efficiently and unambiguously. > > > > > > 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
I've been following this discussion pretty closely and it seems to me that all the arguments in favor of adding this are actually good arguments for converting ALL fatal errors to exceptions. I see no compelling reason to change just this one type of error to an exception, and in fact, changing just this one error feels awkward and kludgey so I wouldn't really support that. Even Peter's recent objection (Law of Demeter) mostly derives strength from the fact that this is a one off change. If all fatal errors were replaced with exceptions there would be plenty of perfectly valid use cases that don't break encapsulation. There was an RFC for replacing "errors" with exceptions a while back, but it was a disaster (didn't even cover the (fatal) error cases, wanted to replace all warnings with exceptions, focused on things that were already recoverable, etc.) It was the wrong solution to the wrong problem. I don't want anything I say here to be confused with that. I think I do like the idea of (optionally?) replacing fatal errors with exceptions, but only if it is a general paradigm change. If you are only going to replace one error, then I don't like the idea because it is inconsistent and makes core changes to support one person's use case without considering what the overall need really is. John Crenshaw Priacta, Inc.
