On Dec 10, 2014, at 4:12 PM, Christoph Becker <cmbecke...@gmx.de> wrote:
> Josh Watzman wrote:
>
>> 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.
>
> FWIW, there is a third option: instead of returning null, return a null
> object[1]. That causes (slightly) more overhead, but it's quite
> flexible and works rather nicely without requiring the (IMO) ugly ?->
> nor exception handling.
>
> Consider a non-existent user "foo":
>
> User::find('foo')?->getName() // returns null
>
> User::find('foo')->getName() // could also return '' or 'Unknown user'
This is actually what the implementation does behind the scenes, but issues
with this approach actually being visible to userlevel code is what prompted
the feature in the first place :) The biggest problem is that you can
accidentally leak your null object, which causes the calling code to
unexpectedly swallow errors; with the ?-> operator, you know you're always
immediately using the null object, there's no way to hold onto it. Smaller
problems are that you either need a different null object for every object you
want to use this with, or a single general one with __call, which is ugly and
hard to optimize. It's also impossible to typecheck, but that was a problem for
Hack and is pretty irrelevant to PHP.
It's also worth noting that doing this with a null object would have the same
lack of short circuiting that I've been arguing for ;)
Josh
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
