Re: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)
In me experience the more errors are thrown (instead of hidden and recovered from) the better - you will clear much quicker the bugs. If we have this case as recoverable (and possibly others) then you would have to write a some of try/catchs... Instead you can avoid throwing the errors by writing the same amount of lines as checks/conditions. I just dont think this will save any effort form the developers side... in fact I think the opposite - in case you have misbehaving exception handler you may miss some errors. On Wed, Feb 22, 2012 at 11:26 PM, John Crenshaw wrote: > > From: Ferenc Kovacs [mailto:tyr...@gmail.com] > > Sent: Wednesday, February 22, 2012 3:55 PM > > To: John Crenshaw > > Cc: Peter Lind; Larry Garfield; internals@lists.php.net > > Subject: Re: [PHP-DEV] Exceptions for method on non-object rather than > fatal (desired feature?) > > > > don't forget that we can't replace all fatals with exception, because by > design fatal errors are used when "errors that can not be recovered from, > such as a memory allocation problem". > I agree that we tend to raise fatals in some/many cases > where E_RECOVERABLE_ERROR or throwing exception would be more appropriate. > > > > -- > > Ferenc Kovács > > @Tyr43l - http://tyrael.hu > > I didn't forget about OOM and other truly fatal errors. I actually > considered mentioning it but decided that specific details should be > ignored unless/until people decided they wanted to discuss it at that level. > > While there are some truly fatal problems (such as OOM), most "fatal" > problems are really recoverable if you are allowed to unwind the stack to a > known stable point (which is exactly what you get when you catch an > exception). A good example would be E_PARSE; no amount of willingness to > continue can allow the parser to recover or allow the problem file to > execute, but if an exception were thrown and caught up the stack > (autoloaders), it would be possible to continue from there. > (null)->foo() and other critical logic failures fall into the same > category; it isn't safe to continue linearly, but you can unwind the stack. > Based on my experience truly fatal problems are horribly rare. Probably > around 99% of the "fatal" errors I see on a regular basis would have been > recoverable using exceptions. > > John Crenshaw > Priacta, Inc. > -- Vesselin Kenashkov Senior developer at azonmedia <http://azonmedia.com>
Re: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)
And with the latter, you've reduced the amount of checks you have to do, by putting them in the proper places (if baby and mother objects inherit from the same class you've essentially got one check on null inside getMother(), not many spread out in client code). Also, the client code now only knows about the immediate surroundings - and should obviously know if getGrandmother() or getGrandmotherName() can throw exceptions. So as far as I'm concerned, the feature proposed just makes it a easier to couple your code more tightly. I'd rather the language discouranged that - or at least not encourage it. Regards Peter The example is a simplified illustration of the case, it's not literally the reason I want to have an exception here. I will take my time to make this very clear in the RFC. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: l...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)
> From: Ferenc Kovacs [mailto:tyr...@gmail.com] > Sent: Wednesday, February 22, 2012 3:55 PM > To: John Crenshaw > Cc: Peter Lind; Larry Garfield; internals@lists.php.net > Subject: Re: [PHP-DEV] Exceptions for method on non-object rather than fatal > (desired feature?) > > don't forget that we can't replace all fatals with exception, because by > design fatal errors are used when "errors that can not be recovered from, > such as a memory allocation problem". I agree that we tend to raise fatals in some/many cases where E_RECOVERABLE_ERROR or throwing exception would be more appropriate. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu I didn't forget about OOM and other truly fatal errors. I actually considered mentioning it but decided that specific details should be ignored unless/until people decided they wanted to discuss it at that level. While there are some truly fatal problems (such as OOM), most "fatal" problems are really recoverable if you are allowed to unwind the stack to a known stable point (which is exactly what you get when you catch an exception). A good example would be E_PARSE; no amount of willingness to continue can allow the parser to recover or allow the problem file to execute, but if an exception were thrown and caught up the stack (autoloaders), it would be possible to continue from there. (null)->foo() and other critical logic failures fall into the same category; it isn't safe to continue linearly, but you can unwind the stack. Based on my experience truly fatal problems are horribly rare. Probably around 99% of the "fatal" errors I see on a regular basis would have been recoverable using exceptions. John Crenshaw Priacta, Inc.
Re: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)
> > > 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. > don't forget that we can't replace all fatals with exception, because by design fatal errors are used when "errors that can not be recovered from, such as a memory allocation problem". I agree that we tend to raise fatals in some/many cases where E_RECOVERABLE_ERROR or throwing exception would be more appropriate. for those(not you) who think that every notice/warning/error could be turned into exceptions, I would like to repeat something that was mentioned every time when this topic is brought up: - a single php expression/call can raise multiple warnings/notices/errors what would happen those if we would want to turn those into exceptions? - currently there are many functions/extensions where a notice/warning is issued to raise the developers attention about a potential problem, but that doesn't stop the code execution (except if you have an error handler and explicitly aborts the execution), and the call will return the expected result. if those warnings/notices would be turned to exceptions, how could you fetch the return value of that expression/call? to reply to the original proposal which started the thread: I think that the example is lazy and error-prone code, if you can't guarantee the return value of your method calls, you shouldn't chain those. adding another "magic" to php for people being able to write sloppy code easier doesn't really cut it for me. On the other hand I can agree that it would be more OOPis, if calling a non-existent method on an __object__ could throw an exception (MissingMethodException or MethodNotFoundException). -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)
> -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" wrote: > > > > On 2/21/12 5:45 PM, Tjerk Meesters wrote: > >> > >> On 22 Feb, 2012, at 2:03 AM, Ralf Lang 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.
Re: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)
On 22 February 2012 20:04, Larry Garfield wrote: > 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? > > > --Larry Garfield > As I wrote, the law of Demeter (http://en.wikipedia.org/wiki/Law_Of_Demeter) The OP started out with this code example, as a reason to introduce the change: $granny_name = $baby->getMother()->getMother()->getName(); The code shouldn't be aware of all the links, it's a bad habit. Rewrite to: $granny_name = $baby->getGrandmother()->getName() or $granny_name = $baby->getGrandmotherName(); And with the latter, you've reduced the amount of checks you have to do, by putting them in the proper places (if baby and mother objects inherit from the same class you've essentially got one check on null inside getMother(), not many spread out in client code). Also, the client code now only knows about the immediate surroundings - and should obviously know if getGrandmother() or getGrandmotherName() can throw exceptions. So as far as I'm concerned, the feature proposed just makes it a easier to couple your code more tightly. I'd rather the language discouranged that - or at least not encourage it. Regards Peter -- WWW: plphp.dk / plind.dk LinkedIn: plind BeWelcome/Couchsurfing: Fake51 Twitter: kafe15 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)
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? --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)
On Feb 22, 2012 7:05 PM, "Larry Garfield" wrote: > > On 2/21/12 5:45 PM, Tjerk Meesters wrote: >> >> On 22 Feb, 2012, at 2:03 AM, Ralf Lang 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
Re: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)
On 2/21/12 5:45 PM, Tjerk Meesters wrote: On 22 Feb, 2012, at 2:03 AM, Ralf Lang 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
Re: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)
On 22 Feb, 2012, at 2:03 AM, Ralf Lang 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. > -- > Ralf Lang > Linux Consultant / Developer > Tel.: +49-170-6381563 > Mail: l...@b1-systems.de > > B1 Systems GmbH > Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de > GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)
On 21/02/12 19:03, Ralf Lang 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 effort 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. return new NoMother; -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)
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. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: l...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)
On 21/02/12 17:06, Ralf Lang wrote:
> Am 21.02.2012 16:55, schrieb Martin Amps:
>> Could you not implement such functionality within your class as follows:
>>
>> class Family {
>> public function getMother() {
>> if ($this->hasMother())
>> return $someObj;
>> else
>> throw new BadMethodCallException(...);
>> }
>> }
>>
>> try {
>> $granny_name = $baby->getMother()->getMother()->getName();
>> } catch (BadMethodCallException $ex) {
>>
>> }
>>
>> Martin
>
> Hi Martin,
>
> First of all, thank you for your rapid response but it doesn't address
> my question (or at least the question I intended to ask)
>
> of course there is always a way to script around issues rather than
> adressing them. I just want to know if the change would be desired. I
> have code around which does exactly this, check on all levels of all
> possible combinations. Semantically, this is nonsense and it bloats
> the code. It's just a requirement because currently PHP handles this
> as non-recoverable fatal.
>
> 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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)
2012/2/21 Ralf Lang : >>> 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. >> >> >> This topic have been raised many many times (Turning errors into >> Exceptions). > > > What's the result? Should we do it or not? It was a clear no from most core guys, if you want some more detailed answer, try search the internals@ archieve on markmail. > No magic wanted here. Just a yes, want / no, don't want. > What I suggest you to do, if you want this in the core, then write an RFC[1], and propose your suggestion for it to get voted on. [1] http://wiki.php.net/rfc -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)
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. This topic have been raised many many times (Turning errors into Exceptions). What's the result? Should we do it or not? as PHP does not do any magical overloading without explicitly declared, witch I think is a good decision. No magic wanted here. Just a yes, want / no, don't want. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: l...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)
Hi Ralk 2012/2/21 Ralf Lang : > Am 21.02.2012 16:55, schrieb Martin Amps: > of course there is always a way to script around issues rather than > adressing them. I just want to know if the change would be desired. I have > code around which does exactly this, check on all levels of all possible > combinations. Semantically, this is nonsense and it bloats the code. It's > just a requirement because currently PHP handles this as non-recoverable > fatal. > > 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. This topic have been raised many many times (Turning errors into Exceptions). What it seems like you are trying to shave off, is 3 lines, I do know that it is sample code but like Martin replied, you should implement such yourself as PHP does not do any magical overloading without explicitly declared, witch I think is a good decision. TL;DR, in basic terms, if you want it as a one-liner, you must implement the overloading methods yourself to obtain that chaning you are after. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)
Am 21.02.2012 16:55, schrieb Martin Amps:
Could you not implement such functionality within your class as follows:
class Family {
public function getMother() {
if ($this->hasMother())
return $someObj;
else
throw new BadMethodCallException(...);
}
}
try {
$granny_name = $baby->getMother()->getMother()->getName();
} catch (BadMethodCallException $ex) {
}
Martin
Hi Martin,
First of all, thank you for your rapid response but it doesn't address
my question (or at least the question I intended to ask)
of course there is always a way to script around issues rather than
adressing them. I just want to know if the change would be desired. I
have code around which does exactly this, check on all levels of all
possible combinations. Semantically, this is nonsense and it bloats the
code. It's just a requirement because currently PHP handles this as
non-recoverable fatal.
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.
--
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: l...@b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Exceptions for method on non-object rather than fatal (desired feature?)
Hi list,
I am aware this question might have been discussed to death but I did
some googling on $subject and watched the bug/feature tracker and it
seems most entries on this issue are old and unanswered.
Is there a design decision or hard-to-overcome engine limitation which
prevents turning method-on-nonobject into a catchable Exception? Or did
just nobody step up and provide a patch?
Rationale:
In another language/framework context I did a lot of chained/nested
stuff like this:
$granny_name = $baby->getMother()->getMother()->getName();
In PHP I would rather do
$mother = $baby->getMother();
if ($mother) {
$granny = $mother->getMother();
if ($granny) {
$granny_name = $granny->getName();
}
}
because I have no way to catch if $mother or $granny cannot be retrieved.
If it's generally welcome I'll try and supply a patch.
(Now let's hope this doesn't start something evil.)
--
Ralf Lang
Linux Consultant / Developer
Mail: l...@b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
