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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
