Everything

php

Fatal errors

php.internals

Michael Walter

20 years ago

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

Lukas Smith

20 years ago

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

Michael Walter

20 years ago

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

On 8/10/06, Lukas Kahwe Smith <lsmith@php.net> wrote:

Pierre Joye

20 years ago

Hello,

On 8/10/06, Michael Walter <michael.walter@gmail.com> wrote:

> 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

Lukas Smith

20 years ago

Pierre wrote:

> Hello,
>
> On 8/10/06, Michael Walter <michael.walter@gmail.com> wrote:
>> 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

Michael Walter

20 years ago

That doesn't justify the error being non-recoverable, though.

Regards,
Michael

On 8/10/06, Lukas Kahwe Smith <lsmith@php.net> wrote:

Derick Rethans

20 years ago

On Thu, 10 Aug 2006, Pierre wrote:

> On 8/10/06, Michael Walter <michael.walter@gmail.com> wrote:
> > 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

Pierre Joye

20 years ago

Hello,

On 8/10/06, Derick Rethans <derick@php.net> wrote:

> On Thu, 10 Aug 2006, Pierre wrote:
>
> > On 8/10/06, Michael Walter <michael.walter@gmail.com> wrote:
> > > 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

Michael Walter

20 years ago

Hi,

On 8/10/06, Derick Rethans <derick@php.net> wrote:

> 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

Ilia A.

20 years ago

On 10-Aug-06, at 6:02 AM, 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?

I for one think that the current behavior is the correct one and see
no need to change it.

Ilia Alshanetsky

Michael Walter

20 years ago

What do you feel is incorrect about allowing mentioned errors to be
handled in userspace?

Regards,
Michael

On 8/10/06, Ilia Alshanetsky <ilia@prohost.org> wrote:

Ilia A.

20 years ago

On 10-Aug-06, at 9:35 AM, Michael Walter wrote:

> 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

Unknown W. Brackets

20 years ago

In the past, many softwares have used an error handler function to
provide the following cases:

1. Log the error in a more complicated way than PHP does by default.
2. Send off an email, if necessary, or communicate with another service.
3. 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 --------

Derick Rethans

20 years ago

On Thu, 10 Aug 2006, Ilia Alshanetsky wrote:

>
> On 10-Aug-06, at 9:35 AM, Michael Walter wrote:
>
> > 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

Pierre Joye

20 years ago

Hello,

On 8/10/06, Derick Rethans <derick@php.net> wrote:

> On Thu, 10 Aug 2006, Ilia Alshanetsky wrote:
>
> >
> > On 10-Aug-06, at 9:35 AM, Michael Walter wrote:
> >
> > > 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

Marcus Börger

20 years ago

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