Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [PATCH] make "Call to a member function on a non-object" non-fatal »

[PATCH] make "Call to a member function on a non-object" non-fatal

php.internals

Morten Poulsen

23 years ago
Hi, The attached patch (against zend_execute.c 1.316.2.10) changes a "Call to a member function on a non-object" from E_ERROR to E_WARNING so it can be handled by a "user space" error handler. Best regards, Morten Poulsen
-- Morten Poulsen <morten+php@afdelingp.dk>

Per Lundberg

23 years ago
On Fri, 2003-05-23 at 17:43, Morten Poulsen wrote:
> The attached patch (against zend_execute.c 1.316.2.10) changes a "Call > to a member function on a non-object" from E_ERROR to E_WARNING so it > can be handled by a "user space" error handler.
I think this patch is bad. It distorts the control flow of a normal program. Calling member functions on a non-object is a serious error, so the only real option IMO is dying, or throwing an exception.
-- Best regards, Per Lundberg / Capio ApS Phone: +46-18-4186040 Fax: +46-18-4186049 Web: http://www.nobolt.com

Andrei Zmievski

23 years ago
On Fri, 23 May 2003, Per Lundberg wrote:
> I think this patch is bad. It distorts the control flow of a normal > program. Calling member functions on a non-object is a serious error, > so the only real option IMO is dying, or throwing an exception.
I agree. -Andrei * I wish life had an UNDO function. *

Morten Poulsen

23 years ago
On Fri, 2003-05-23 at 18:00, Per Lundberg wrote:
> I think this patch is bad. It distorts the control flow of a normal > program. Calling member functions on a non-object is a serious error, > so the only real option IMO is dying, or throwing an exception.
The patch might not be the right way to implement it. Calling a member function on null happens from time to time, when programmers don't check the return value of a library call. In a production environment it is bad, not having the option to handle the error, therefore it is bad to just die. Throwing an exception might be a nicer way, but isn't that future? Best regards, Morten
-- Morten Poulsen <morten+php@afdelingp.dk>

Andrei Zmievski

23 years ago
On Fri, 23 May 2003, Morten Poulsen wrote:
> The patch might not be the right way to implement it. Calling a member > function on null happens from time to time, when programmers don't check > the return value of a library call. In a production environment it is > bad, not having the option to handle the error, therefore it is bad to > just die. Throwing an exception might be a nicer way, but isn't that > future?
Calling a member function on a null should not even happen in production environment, if you architecture your application properly. -Andrei "The most exciting phrase to hear in science, the one that heralds new discoveries, is not "Eureka!" but "That's funny..." -- Isaac Asimov.

Morten Poulsen

23 years ago
On Fri, 2003-05-23 at 23:57, Andrei Zmievski wrote:
> Calling a member function on a null should not even happen in production > environment, if you architecture your application properly.
Correct. "Should not," but they do.
-- Morten Poulsen <morten+php@afdelingp.dk>

Derick Rethans

23 years ago
On Sat, 24 May 2003, Morten Poulsen wrote:
> On Fri, 2003-05-23 at 23:57, Andrei Zmievski wrote: > > Calling a member function on a null should not even happen in production > > environment, if you architecture your application properly. > > Correct. "Should not," but they do.
We can not prevent everybody's mistakes. There are enough other ways to shoot yourself in the knee. Derick
-- "my other box is your windows PC" ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ International PHP Magazine http://php-mag.net/ -------------------------------------------------------------------------

George Schlossnagle

23 years ago
On Friday, May 23, 2003, at 06:08 PM, Morten Poulsen wrote:
> On Fri, 2003-05-23 at 23:57, Andrei Zmievski wrote: >> Calling a member function on a null should not even happen in >> production >> environment, if you architecture your application properly. > > Correct. "Should not," but they do.
Code shouldn't have parse errors either, but it sometimes does. Should we protect against that as well? Andrei's point is that with simple error checking you can handle this case. Your developers being too sloppy/lazy to take these basic steps doesn't mean that php should do it for them. Their is an ongoing thread regarding converting a number of E_ERROR errors to exceptions for php5. This case clearly fits well into that idea. George

Derick Rethans

23 years ago
On Fri, 23 May 2003, Morten Poulsen wrote:
> The attached patch (against zend_execute.c 1.316.2.10) changes a "Call > to a member function on a non-object" from E_ERROR to E_WARNING so it > can be handled by a "user space" error handler.
It should fail, E_ERROR is just fine. Derick
-- "my other box is your windows PC" ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ International PHP Magazine http://php-mag.net/ -------------------------------------------------------------------------