Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66727
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.43 as permitted sender)
Message-ID: <514A05BA.90409@gmail.com>
Date: Wed, 20 Mar 2013 11:53:46 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: internals@lists.php.net
References: <CANa7=gxotTUa=56qGw5qCqx7k9J2COztqk9XhsPeYZXrKyFLiw@mail.gmail.com> <CACwt+Jfp3bxoC0raeHFSMNJS09fZa=oBWXbuVO5nUg0_c17KfA@mail.gmail.com> <CANa7=gy2eqNPQu4ERNC_PEGYfZSQ=SavnXbc70fZV+=eq0894A@mail.gmail.com> <CANa7=gyxu+2vE=4zZH83K3MaTZm_EtuyRCkjJ+xYNDRHShWO4Q@mail.gmail.com>
In-Reply-To: <CANa7=gyxu+2vE=4zZH83K3MaTZm_EtuyRCkjJ+xYNDRHShWO4Q@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Method check - Can someone create a RFC for it?
From: mjpelmear@gmail.com (Matt Pelmear)

On 03/20/2013 11:43 AM, Carlos Rodrigues wrote:
> Like Mike emaild me, i can just change my code to something like
> $obj->getImage()->getUrl(), where getImage() will return a mock object
> with getUrl() returning an empty string.
>
> But my request here is not about this case only.
> Imagine you have a web page with 3 blocks of information. Let's say
> "news", "partners" and "blog".
>
> Now if for some reason you didn't code it right, you might get a fatal
> error in one of these "blocks".
>
> I'd love to have a way to try/catch these blocks, Currently i can only
> do this using ajax, or running shell exec "php block.php" for each
> one.
>
> If we could catch fatal errors, or at least the "Call to a member
> function on a non-object", we could have this code in our Zend
> Framework implementations, wrapping each view in a try/catch, and
> showing a "error, sorry", in case the view has errors.
>
> - Carlos
>

Carlos,

You should take a look at the other thread that's been in the internals 
group over the last day or so. There is an effort to see cases like this 
become E_RECOVERABLE_ERRORs, which I think would address what you're 
really looking for. (In fact, this particular error is mentioned first 
in that thread.)

But I would argue that, while this is a change I support, this is not a 
substitute for proper testing prior to code deployment (as others have 
pointed out).

-Matt