# Method check - Can someone create a RFC for it?

- Thread: https://externals.io/message/66722
- Original archive: https://news-web.php.net/php.internals/66722
- Started by Carlos Rodrigues on 2013-03-20T18:08:20+00:00
- Messages: 11
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #66722 — Carlos Rodrigues — 2013-03-20T18:08:20+00:00

URL: https://externals.io/message/66722#66722

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

---

## #66723 — Patrick ALLAERT — 2013-03-20T18:22:12+00:00

URL: https://externals.io/message/66722#66723 · In reply to: #66722

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

---

## #66724 — nathan@starin.biz — 2013-03-20T18:40:56+00:00

URL: https://externals.io/message/66722#66724 · In reply to: #66722

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

---

## #66725 — Carlos Rodrigues — 2013-03-20T18:43:36+00:00

URL: https://externals.io/message/66722#66725

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
>
> 
> > […]

---

## #66726 — Sanford Whiteman — 2013-03-20T18:49:46+00:00

URL: https://externals.io/message/66722#66726 · In reply to: #66722

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

---

## #66727 — Matt Pelmear — 2013-03-20T18:53:46+00:00

URL: https://externals.io/message/66722#66727 · In reply to: #66725

> 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

---

## #66728 — johannes@schlueters.de — 2013-03-20T19:05:58+00:00

URL: https://externals.io/message/66722#66728 · In reply to: #66722

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

---

## #66729 — Frank Liepert — 2013-03-20T19:09:08+00:00

URL: https://externals.io/message/66722#66729 · In reply to: #66722

> -----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?

---

## #66730 — Pierre du Plessis — 2013-03-20T20:01:52+00:00

URL: https://externals.io/message/66722#66730 · In reply to: #66727

>  Like Mike emaild me, i can just change my code to something like
> > […]
> 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

---

## #66731 — Stas Malyshev — 2013-03-20T20:22:22+00:00

URL: https://externals.io/message/66722#66731 · In reply to: #66722

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

---

## #66742 — Tjerk Meesters — 2013-03-21T23:41:22+00:00

URL: https://externals.io/message/66722#66742 · In reply to: #66722

> 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