Re: [RFC] Nullsafe calls

From: Date: Wed, 10 Dec 2014 19:20:52 +0000
Subject: Re: [RFC] Nullsafe calls
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-79543@lists.php.net to get a copy of this message
Hi again. > On 10 Dec 2014, at 19:11, Josh Watzman <jwatzman@fb.com> wrote: > > On Dec 10, 2014, at 9:19 AM, Andrea Faulds <ajf@ajf.me> wrote: > >> First, how is this substantially different from catching an exception? With Nikita’s >> Exceptions in the Engine RFC, something like this would be possible: >> >> try { >> return $foo->bar()->qux()->elePHPant()->dance(); >> } catch (EngineException $e) { >> return NULL; >> } >> >> That would essentially do the same as what you’re proposing: >> >> return $foo?->bar()?->qux()?->elePHPant()?->dance(); >> >> Are there many instances where there’d be a substantial benefit to using ?-> versus >> catching an exception? > > It's an API decision up to the implementors of the object. If you like using exceptions > for *every* failure, then go for it, this syntax won't cost you anything or get in your way :) > > However, for a lot of failures, I don't feel that exceptions are appropriate. I tend to > only use them for exceptional behavior -- usually, some failure that needs to be propagated up a few > levels up the stack, to an appropriate error boundary. This doesn't necessarily mean a > completely unrecoverable error, but it's *locally* unrecoverable. For things that are > completely recoverable, returning null might be more appropriate and more lightweight, and then this > nullsafe operator would be useful at that point. …huh? I’m not talking about exceptions the object itself throws. In PHP 7, if Nikita’s RFC passes, trying to call a method on NULL will throw an exception. That largely negates the need for a special operator, since you can just catch the exception. Thanks. -- Andrea Faulds http://ajf.me/

« previous php.internals (#79543) next »