Hi again.
> On 10 Dec 2014, at 19:11, Josh Watzman <jwatz...@fb.com> wrote:
>
> On Dec 10, 2014, at 9:19 AM, Andrea Faulds <a...@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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
