Hi,
right now, PHP triggers fatal errors e.g. when accessing private
members or calling nonexistant functions. Since this is problematic
for obvious reasons, what technical reasons are there for that
behavior, and is there a chance that this behaviour will change in a
future release?
Regards,
Michael
Michael Walter wrote:
Hi,
right now, PHP triggers fatal errors e.g. when accessing private
members or calling nonexistant functions. Since this is problematic
for obvious reasons, what technical reasons are there for that
behavior, and is there a chance that this behaviour will change in a
future release?
what is "problematic" here? Are you simply suggesting to make them
E_RECOVERABLE since they do not really leave the engine in a broken state?
regards,
Lukas
Yeah. It is problematic that the application has no chance of dealing
with the errors itself (consider e.g. php-shell which has to go great
lengths to prevent fatal errors from user code leading to php-shell's
termination, and still fails at doing this in the general case).
Regards,
Michael
Michael Walter wrote:
Hi,
right now, PHP triggers fatal errors e.g. when accessing private
members or calling nonexistant functions. Since this is problematic
for obvious reasons, what technical reasons are there for that
behavior, and is there a chance that this behaviour will change in a
future release?what is "problematic" here? Are you simply suggesting to make them
E_RECOVERABLE since they do not really leave the engine in a broken state?regards,
Lukas
Hello,
Yeah. It is problematic that the application has no chance of dealing
with the errors itself (consider e.g. php-shell which has to go great
lengths to prevent fatal errors from user code leading to php-shell's
termination, and still fails at doing this in the general case).
Why object should act differently than other php variables or
constants? Undefined constant, variable, index or offset do not raise
a fatal error. It should be the same for the object (constants, props,
visibility,...).
--Pierre
Pierre wrote:
Hello,
Yeah. It is problematic that the application has no chance of dealing
with the errors itself (consider e.g. php-shell which has to go great
lengths to prevent fatal errors from user code leading to php-shell's
termination, and still fails at doing this in the general case).Why object should act differently than other php variables or
constants? Undefined constant, variable, index or offset do not raise
a fatal error. It should be the same for the object (constants, props,
visibility,...).
Well for privat variables it is kind of different in that someone
specifically said "this variable/property exists, but you may only
access is from inside and not from the outside".
regards,
Lukas
That doesn't justify the error being non-recoverable, though.
Regards,
Michael
Pierre wrote:
Hello,
Yeah. It is problematic that the application has no chance of dealing
with the errors itself (consider e.g. php-shell which has to go great
lengths to prevent fatal errors from user code leading to php-shell's
termination, and still fails at doing this in the general case).Why object should act differently than other php variables or
constants? Undefined constant, variable, index or offset do not raise
a fatal error. It should be the same for the object (constants, props,
visibility,...).Well for privat variables it is kind of different in that someone
specifically said "this variable/property exists, but you may only
access is from inside and not from the outside".regards,
Lukas
Yeah. It is problematic that the application has no chance of dealing
with the errors itself (consider e.g. php-shell which has to go great
lengths to prevent fatal errors from user code leading to php-shell's
termination, and still fails at doing this in the general case).Why object should act differently than other php variables or
constants? Undefined constant, variable, index or offset do not raise
a fatal error. It should be the same for the object (constants, props,
visibility,...).
He wasn't talking about undefined variables at all. The variable is
defined as private and calling that is ofcourse not allowed.
The second thing is that calling normal undefined
functions throws a fatal error as well, and it should do that just like
calling non existing methods on an object should throw a fatal error.
regards,
Derick
Hello,
Yeah. It is problematic that the application has no chance of dealing
with the errors itself (consider e.g. php-shell which has to go great
lengths to prevent fatal errors from user code leading to php-shell's
termination, and still fails at doing this in the general case).Why object should act differently than other php variables or
constants? Undefined constant, variable, index or offset do not raise
a fatal error. It should be the same for the object (constants, props,
visibility,...).He wasn't talking about undefined variables at all. The variable is
defined as private and calling that is ofcourse not allowed.
I was adding more info to the request. As this problem is not only
about this case.
For example, try:
php -r 'class foo{const bar=2;} echo foo::bar; echo foo::bar2;'
In my opinion, echo foo::bar2; should not be a fatal error, just like
"echo BAR2;".
--Pierre
Hi,
He wasn't talking about undefined variables at all. The variable is
defined as private and calling that is ofcourse not allowed.
I was talking about all kinds of errors which for no good reason are
non-recoverable. Surely, the operation being not allowed is a not a a
good error to make the error non-recoverable.
The second thing is that calling normal undefined
functions throws a fatal error as well, and it should do that just like
calling non existing methods on an object should throw a fatal error.
I'm specifically wondering why these errors need be non-recoverable.
Ideally, userland would be able to handle them (see the other mails
for the rationale).
Regards,
Michael
Hi,
right now, PHP triggers fatal errors e.g. when accessing private
members or calling nonexistant functions. Since this is problematic
for obvious reasons, what technical reasons are there for that
behavior, and is there a chance that this behaviour will change in a
future release?
I for one think that the current behavior is the correct one and see
no need to change it.
Ilia Alshanetsky
What do you feel is incorrect about allowing mentioned errors to be
handled in userspace?
Regards,
Michael
Hi,
right now, PHP triggers fatal errors e.g. when accessing private
members or calling nonexistant functions. Since this is problematic
for obvious reasons, what technical reasons are there for that
behavior, and is there a chance that this behaviour will change in a
future release?I for one think that the current behavior is the correct one and see
no need to change it.Ilia Alshanetsky
What do you feel is incorrect about allowing mentioned errors to be
handled in userspace?
My feeling is that errors such as visibility violations should be
addressed during debugging and Q&A phase where simple error logging
will be sufficient to track them.
Ilia Alshanetsky
In the past, many softwares have used an error handler function to
provide the following cases:
- Log the error in a more complicated way than PHP does by default.
- Send off an email, if necessary, or communicate with another service.
- Show a generic (e.g. a 500) error message to the client.
Now, if I have display_errors set to 0, and my code calls a function
that does not exist, or a property it doesn't have access to, the user
will see a blank screen (or whatever has been outputted thus far.)
Obviously any such egregious errors should have been caught before the,
let's say, build got to the beta tester or end client... but by the same
logic segfaults should never be found in production C code either.
Guess that never happens too, right?
In fact, the example on the ref.errorfunc.php doc page shows exactly the
sort of thing that is not possible for these types of errors now.
Simple error logging seems to fall apart, though, because when your
software is on a box you have no control over... and an end user gets an
error the end client doesn't even know about, you typically never find
out. Even if the end client has opted to send you any errors that happen.
-[Unknown]
-------- Original Message --------
What do you feel is incorrect about allowing mentioned errors to be
handled in userspace?My feeling is that errors such as visibility violations should be
addressed during debugging and Q&A phase where simple error logging will
be sufficient to track them.Ilia Alshanetsky
What do you feel is incorrect about allowing mentioned errors to be
handled in userspace?My feeling is that errors such as visibility violations should be addressed
during debugging and Q&A phase where simple error logging will be sufficient
to track them.
And I feel this is even more true for calling undefined functions or
methods...
regards,
Derick
Hello,
What do you feel is incorrect about allowing mentioned errors to be
handled in userspace?My feeling is that errors such as visibility violations should be addressed
during debugging and Q&A phase where simple error logging will be sufficient
to track them.And I feel this is even more true for calling undefined functions or
methods...
Ok, I repeat again what I said, please read:
<?php
error_reporting(E_ALL);
class foo{const bar=2; }
echo foo::bar2;
?>
It has nothing to do with undefined function or method. Having a fatal
error here is insane.
--Pierre
Hello Michael,
this is the expected behavior. But we migth as well simply remove all
those modifiers. That would be much better then providing them in a
senseless manner.
regards
marcus
Thursday, August 10, 2006, 12:02:09 PM, you wrote:
Hi,
right now, PHP triggers fatal errors e.g. when accessing private
members or calling nonexistant functions. Since this is problematic
for obvious reasons, what technical reasons are there for that
behavior, and is there a chance that this behaviour will change in a
future release?
Regards,
Michael
Best regards,
Marcus