Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79551
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.21 as permitted sender)
Message-ID: <5488E187.9010801@gmx.de>
Date: Thu, 11 Dec 2014 01:12:55 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Josh Watzman <jwatzman@fb.com>, Andrea Faulds <ajf@ajf.me>
CC: PHP internals <internals@lists.php.net>
References: <95A581EE-A062-4926-BE44-BCA87FC9B356@fb.com> <9230CB24-22FC-4A0E-A9D5-F02523B65A02@ajf.me> <583B9A4B-68FD-4FB1-B043-0D86E2480EAD@fb.com>
In-Reply-To: <583B9A4B-68FD-4FB1-B043-0D86E2480EAD@fb.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Nullsafe calls
From: cmbecker69@gmx.de (Christoph Becker)

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'

[1] <http://en.wikipedia.org/wiki/Null_Object_pattern>

-- 
Christoph M. Becker