Re: [RFC] Nullsafe calls
| From: | Andrea Faulds | 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/