On 21 Mar, 2013, at 2:08 AM, Carlos Rodrigues <carlos.v...@gmail.com> wrote:

> Hi,
> 
> I'd like to suggest a new functionality for PHP. I don't know the
> internals, and i can't create a patch implementing this. I'm writing
> here in case someone likes this idea and write a RFC.
> 
> We've had a problem recently where one of our developers forgot an "if".
> 
> So instead of writing
> if ($obj->image) {
> echo $obj->image->getUrl();
> }
> 
> He wrote:
> echo $obj->image->getUrl();
> 
> Here, locally, it was working cause we had the image. But when we
> updated the online version we got a "Fatal error: Call to a member
> function getUrl() on a non-object" cause someone didn't upload the
> image in one of the records that we're on the home page.
> 
> Fatal errors like this can't be catched by a try/catch. And since this
> getUrl() was not essential for the page, we'd better output an empty
> string then having the site offline.

You can register a shutdown function with register_shutdown_function() and 
check for error_get_last() inside. 

In most cases you can't really handle this particular error very well anyway. 
At least with this you can have the full error emailed to you if you wish and 
print some kind of error message on the page. 

> 
> One might say: "you guys should have tested it better", or "The image
> field should be mandatory in the back end."
> And it's true, he should have written that extra "if {}".
> 
> Examining this problem we happened to stumble open Ruby's and
> Coffescript's method check.
> Something like this:
> 
> $obj->image?->getUrl()?;
> 
> So my suggestion is:
> 
> Create something like $foo->bar?() or $foo->bar()?, where you don't
> care whether the function exists, or if $foo is an object. If it
> doesn't exist you just return null.
> I guess there are plenty of systems out there where it's better to
> output an empty string than having your site offline, just cause the
> programmer couldn't test it completely.
> 
> Thanks for reading it.
> 
> Carlos Rodrigues
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to