Re: Calling method on non-object recoverable? (was: typehinting throwing a fatal error)

From: Date: Fri, 26 Aug 2005 18:25:00 +0000
Subject: Re: Calling method on non-object recoverable? (was: typehinting throwing a fatal error)
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-18480@lists.php.net to get a copy of this message 
Michael Sims wrote:


Derick Rethans wrote:
 

Since this new error level is being created, I have a suggestion for
another type of error I would very much like to see changed from
fatal to "recoverable".  The error I'm referring to is attempting to
call a method on a non-object.  This used to be a E_WARNING a long
time ago in PHP 4 (if memory serves), and is now fatal.
This should stay a fatal error, you're obvious doing something wrong, and it leaves the engine in a somewhat unstable state. Ok. I can understand wanting to keep this a fatal error if the engine might become unstable. As for "obviously doing something wrong", I don't see how calling a method on a non-object is any more obviously wrong than passing the wrong type of argument to a method/function that has a typehint. Both of them are wrong (whether obviously or otherwise), and both of them can be avoided, so it seems to me there is little difference. At any rate, I think there is value in giving PHP users more control over error handling, and reducing where possible the number of errors than cannot be caught by a custom error handler. To me it is not a question of whether or not the code is "right" (it's an error, so by definition it isn't), it's a question of giving PHP users more control and increasing their ability to write more robust applications. Thanks for your time... +1 The ability to catch as many errors as possible is important to me, as a user. It allows me to show pretty errors, and/or hide error output from users, especially in production environments, or show verbose errors with stacktraces while I am in development. Obviously, I can turn display_errors = off for production, but then I can't display to the user that an error occurred at all. And I want to have custom logs of errors. The more errors I can't catch, the more errors I have to look in 2 logs to find. Sometimes it's really useful in the instance of calling a method on a non-object to look at the stacktrace, especially in complex code. I wouldn't even care if PHP didn't allow the script to continue after the error handler did it's job. Of course, if the engine is unstable, it's unstable. But if at all possible, I'd like to catch this particular error. John LeSueur

Thread (125 messages)

« previous php.internals (#18480) next »