Exceptions instead of Fatal Error when calling non existent method?

17 years ago by thrthr@gmail.com — view source — reply

unread

Hi!

I've never posted on internal before, but I've been a long time reader
of it. I've been using PHP for a long time, I think it all started
back in 2000 sometime, anyway - this is hardly a place to put my
entire php biography up for show, so I'll jump right to the action.

Ever since PHP5 and the much improved object model (exceptions, and
what not) there has been one thing missing (at least for me) the whole
time. When you call a method (and function, but this doesn't really
matter from an OO perspective) on an object that does not exist, you
get a "Fatal error: Call to undefined method Foo::bar() in
C:\www\index.php on line 4".

What I would like to argue/request is that there should be a way to
get an exception thrown when you call a non existent method on an
object, since it's not possible to catch E_ERROR with a user defined
function using set_error_handler() I can't see anyway to accomplish
this in the current implementation?

Why do you want this? To allow for "true" duck typing (which I think
fits good into PHP's dynamic nature) without having the risk of your
application running into fatal errors and now having to use
if(method_exists($obj, $method)) on every call I want to make.

I've come up with a couple of suggestions on how this could be
implemented, but I'm not very good with the inner workings of php /
zend engine (I've read parts of Saras book, but that's about it) so I
don't know how hard (or easy) any of these suggestions would be to
implement:

a) Change the error raised when running into an unknown method call
into it's own type that is fatal if not caught by an user defined
error handler?

b) Change the error raised to E_WARNING

c) Change the error raised to E_RECOVERABLE_ERROR which as far as I
can make out is possible to handle with a user defined error handler?

d) Make the engine throw an exception of a special type when an
unknown method is called, possibly provide an php.ini-setting so you
can toggle between the old (E_ERROR) and the new
(UnkownMethodException) to not break BC?

Thanks for reading my message, regards Fredrik.

17 years ago by Derick Rethans — view source — reply

unread

What I would like to argue/request is that there should be a way to
get an exception thrown when you call a non existent method on an
object, since it's not possible to catch E_ERROR with a user defined
function using set_error_handler() I can't see anyway to accomplish
this in the current implementation?

E_ERROR should during normal runs of your program never be hit in the
first place. If it is something critical that still can be handled,
E_RECOVERABLE_ERROR should be used inside PHP. If that is not the case,
please let us now and we can address that.

As for the calling undefined methods, __call() is your friend.

regards,
Derick

17 years ago by thrthr@gmail.com — view source — reply

unread

What is wrong with __call() ?
See:
http://www.php.net/manual/en/language.oop5.overloading.php

Hi!

Yes, I'm aware of call() but it's very slow. Also it's not feasible to have
all my classes extend a base class with the a call containing a throw
InvalidMethodException, and what if I need to use 3rd party libraries that
make use of call in some other way. __call() is a hack, that, at best, work
50% of the time.

Regards, Fredrik.

17 years ago by Mikko Koppanen — view source — reply

unread

Yes, I'm aware of call() but it's very slow. Also it's not feasible to
have
all my classes extend a base class with the a call containing a throw
InvalidMethodException, and what if I need to use 3rd party libraries that
make use of call in some other way. __call() is a hack, that, at best,
work
50% of the time.

Calling methods without knowing that they exist sounds like a hack to me.
How about using abstract classes or interfaces?

--
Mikko Koppanen

17 years ago by thrthr@gmail.com — view source — reply

unread

2007/12/31, Mikko Koppanen
Calling methods without knowing that they exist sounds like a hack to me. How about using abstract classes or interfaces?

If you look at, for example, python - calling methods that don't
know exists is common practice, it's not a hack from my point of
view. It's just easier to ask forgiveness then permission, to quote
Hopper.

I never understood the direction PHP is heading with type hinting,
static binding (SPL-Types?), etc. While I don't directly oppose it I
don't see any reason for it. I just thought that adding some type of
ability to handle unknown method calls (without forcing every class
to implement __call() in a specific way) would be a nice way for those
of us that want to continue to use php as the dynamic, duck-typed
language we learned. Maybe it will fall on deaf ears, but I thought it
was worth a chance and at least propose it here on internals.

Regards, Fredrik.

17 years ago by thrthr@gmail.com — view source — reply

unread

There is no need to implement __call() in every class,.
Just make sure their parent class implements it.
Yes, I'm well aware of that - but that doesn't really help when taking
into account 3rd party libraries or places where it's not possible
because you don't have control over the base class.

Changing PHP's behavior in a backward-incompatible way that would affect
everyone and forcing everyone to use exceptions seems to be really bad
idea, especially taking into account that your problem can be easily solved
without it.
In my original post I proposed several ways that would not be
backwards incompatible, and maybe I put the subject on the original
message wrong - the key here isn't really exceptions but the ability
to handle unknown method calls without taking the entire process down
with it. Anyway this will be my last post on the subject since I don't
want to spam the list and I think I've expressed all my opinions about
it clearly.

Regards, Fredrik.

17 years ago by Stefan Walk — view source — reply

unread

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 31 December 2007 13:48:52 Antony Dovgal wrote:

Changing PHP's behavior in a backward-incompatible way that would affect
everyone and forcing everyone to use exceptions seems to be really bad
idea, especially taking into account that your problem can be easily solved
without it.

What exactly is the backwards compatibility break here? Without the change,
the code simply dies ... if you don't catch the exception, the code simply
dies ... except you get a backtrace now and can handle the exception if you
want to.

Regards,
Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHeO5UpPjfcppEficRAng4AJ4v4G+PyT07cQTYupTgKFnOA130yQCeKWYy
E2tzkWAHOmIKDc/CZw7Dtjw=
=ArZH
-----END PGP SIGNATURE