> -----Original Message-----
> From: Peter Lind [mailto:[email protected]]
> Sent: Wednesday, February 22, 2012 1:37 PM
> To: Larry Garfield
> Cc: [email protected]
> Subject: Re: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)
>
> On Feb 22, 2012 7:05 PM, "Larry Garfield" <[email protected]> wrote:
> >
> > On 2/21/12 5:45 PM, Tjerk Meesters wrote:
> >>
> >> On 22 Feb, 2012, at 2:03 AM, Ralf Lang<[email protected]> 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.