Method check - Can someone create a RFC for it?

11 years ago by Carlos Rodrigues — view source

unread

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.

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

11 years ago by Patrick ALLAERT — view source

unread

2013/3/20 Carlos Rodrigues carlos.vini@gmail.com:

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.

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.

That's syntactic sugar we can live without as it does not really
encourage good programming practices.
If you don't care about those, then you can already just do:

echo @$obj->image->getUrl();

Patrick

11 years ago by nathan@starin.biz — view source

unread

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.

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
I do not like this idea. The error message "Fatal error: Call to a member
function getUrl() on a non-object" is very straight forward, it should tell
you the line the problem is on and everything and a quick glance should spot
the problem quickly. Granted Yes there are cases were it'd be nice to have
an easy work around, but then you run into the problem similar to what the @
has caused for many people, which libraries and general developers start
using it in many places to keep errors form being thrown and you end up with
code that is even harder to debug because no errors are shown. Another
solution that you could have used is to set $obj->image to a singleton
object that is a placeholder for methods like this which might be set...
something like: http://3v4l.org/utBWP

see: http://www.php.net/manual/en/language.oop5.overloading.php#object.call

But even that is a terrible solution, by showing the error fixed a bug...
bugs need to be fixed.

11 years ago by Sanford Whiteman — view source

unread

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.

[1] Don't do this.

[2] What everyone else said.

[3] If you feel you must, this at least "colors within the lines" a
bit more than '@' by forcing you to set a class as wildcard-able:

class bitbucket {
function __call($name,$arguments){
return "default value";
}
function __get($name){
return new self;
}
}

class myClass extends bitbucket {}

$myInst = new MyClass;
print $myInst->noExist->nexistePas(); // "default value"

[4] Goto [1].

-- S.

11 years ago by johannes@schlueters.de — view source

unread

Carlos Rodrigues carlos.vini@gmail.com wrote:

So instead of writing
if ($obj->image) {
echo $obj->image->getUrl();
}

He wrote:
echo $obj->image->getUrl();

Make the property private and add a getter which can throw an exception if no image is available ...

class C {
private $image;
public function hasImage() { return (bool)$this->image; }
public function getImage() { if (!$this->image) { throw new NoImageException(); } return $this->image; }
}
echo $obj->geImage()->getUrl(); // Exception which can be caught.

No nee dto change the language and add a new cosntruct (which your developer will forget, if he forgets the if already ....)

johannes

11 years ago by Frank Liepert — view source

unread

-----Ursprüngliche Nachricht-----
Von: Carlos Rodrigues [mailto:carlos.vini@gmail.com]
Gesendet: Mittwoch, 20. März 2013 19:08
An: internals@lists.php.net
Betreff: [PHP-DEV] Method check - Can someone create a RFC for it?

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.

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

--

Just one question: Is your developer a template designer?

11 years ago by Stas Malyshev — view source

unread

Hi!

We've had a problem recently where one of our developers forgot an "if".

We clearly have two contradicting directions here. On one hand, we have
people that say giving '1' to a method expecting integer should be an
error, and anything unexpected should generate warnings and errors
because the code should handle exceptional cases explicitly.

On the other hand, we have people who say "no matter what happens, just
plow through and substitute nulls if something is wrong".

Both approaches I guess have their advocates and their fans, and have
good pro and contra arguments. What however I think can not be done is
randomly taking both of these approaches in one language at a whim and
expect it to make sense. PHP has taken enough criticism on this front
and we don't need to add more to it. Either we say "if the call can't be
done it's an error" or we say "if we can't call something we just return
null" but not both. PHP currently treats methods that can't be called as
an error. I think replacing it with "just return null" would not be a
thing most PHP developers would want.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

11 years ago by Tjerk Meesters — view source

unread

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

11 years ago by Carlos Rodrigues — view source

unread

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

Thx for your reply Patrick,

I agree that it's partially syntactic sugar, as you said. But when you do this:

$obj = new stdClass();
echo $obj->foo;

PHP will not if foo is not declared. It will output an empty string.
But if you have a method

echo @$obj->foo();
echo 'end';

It will give you a fatal error.

Even using @ to suppress error messages it won't echo the 'end' part.

Since short array syntax (like [1,2]) was not extremely necessary and
was accepted, maybe someones has a better idea than i had to address
this.

Carlos

2013/3/20 Carlos Rodrigues carlos.vini@gmail.com:

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.

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.

That's syntactic sugar we can live without as it does not really
encourage good programming practices.
If you don't care about those, then you can already just do:

echo @$obj->image->getUrl();

Patrick

11 years ago by Matt Pelmear — view source

unread

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

11 years ago by Pierre du Plessis — view source

unread

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).

I think changing the fatal error to E_RECOVERABLE_ERROR will be a good
option, because if you have a generic error handler, then you won't have to
worry about blank pages on a production server