FAQ
Hi,

PHP often throws fatal errors when it could throw an exception.

Take PHP Fatal error: Non-abstract method foo::bar() must contain
body this error for example. It would be possible to mark this class
as 'invalid' instead and when doing a new foo , throw an exception. Or
if you try really hard then only the method call should throw an
exception.

Or, I was extending ReflectionClass and got Fatal error:
ReflectionClass::getFileName(): Internal error: Failed to retrieve the
reflection object (same happens if you try serialzie / unserialzie on
ReflectionClass as a comment in the manual points out). I could argue
this is an exception and not a fatal.

Let me quote documentation:

Fatal run-time errors. These indicate errors that can not be recovered
from, such as a memory allocation problem. Execution of the script is
halted.

I do not see the above or , indeed , most of fatals I see this sort of
error. Sure, if a malloc call fails, the world has ended and it's time
to die. Otherwise, could we just get an exception so that it can be
handled ?

Thanks

Karoly "chx" Negyesi

Search Discussions

  • Sam E Giles at Jun 17, 2012 at 7:13 pm
    Hi,

    I think the example of the abstract method not containing a body is a bad example, as it is fatal and would normally be caught at compilation in a compiled language. I think these sorts of errors shouldn't be catchable, although, I can see instances where it could be a useful interface but it is only for some edge cases such as loading some concrete implementation that your script has no prior knowledge about, if it's incorrect your application can't recover, but this can be avoided anyway I think.

    Sam
    Sent from my BlackBerry® smartphone

    -----Original Message-----
    From: Karoly Negyesi <karoly@negyesi.net>
    Date: Sun, 17 Jun 2012 12:06:03
    To: <internals@lists.php.net>
    Subject: [PHP-DEV] How hard should PHP try to finish a script?
    Hi,

    PHP often throws fatal errors when it could throw an exception.

    Take PHP Fatal error: Non-abstract method foo::bar() must contain
    body this error for example. It would be possible to mark this class
    as 'invalid' instead and when doing a new foo , throw an exception. Or
    if you try really hard then only the method call should throw an
    exception.

    Or, I was extending ReflectionClass and got Fatal error:
    ReflectionClass::getFileName(): Internal error: Failed to retrieve the
    reflection object (same happens if you try serialzie / unserialzie on
    ReflectionClass as a comment in the manual points out). I could argue
    this is an exception and not a fatal.

    Let me quote documentation:

    Fatal run-time errors. These indicate errors that can not be recovered
    from, such as a memory allocation problem. Execution of the script is
    halted.

    I do not see the above or , indeed , most of fatals I see this sort of
    error. Sure, if a malloc call fails, the world has ended and it's time
    to die. Otherwise, could we just get an exception so that it can be
    handled ?

    Thanks

    Karoly "chx" Negyesi

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • John LeSueur at Jun 17, 2012 at 9:31 pm

    On Sun, Jun 17, 2012 at 1:06 PM, Karoly Negyesi wrote:

    Hi,

    PHP often throws fatal errors when it could throw an exception.

    Take PHP Fatal error: Non-abstract method foo::bar() must contain
    body this error for example. It would be possible to mark this class
    as 'invalid' instead and when doing a new foo , throw an exception. Or
    if you try really hard then only the method call should throw an
    exception.

    Or, I was extending ReflectionClass and got Fatal error:
    ReflectionClass::getFileName(): Internal error: Failed to retrieve the
    reflection object (same happens if you try serialzie / unserialzie on
    ReflectionClass as a comment in the manual points out). I could argue
    this is an exception and not a fatal.

    Let me quote documentation:

    Fatal run-time errors. These indicate errors that can not be recovered
    from, such as a memory allocation problem. Execution of the script is
    halted.

    I do not see the above or , indeed , most of fatals I see this sort of
    error. Sure, if a malloc call fails, the world has ended and it's time
    to die. Otherwise, could we just get an exception so that it can be
    handled ?

    Thanks

    Karoly "chx" Negyesi

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    This kind of thing has come up before, without resolution. There are two
    separate issues in your proposal:

    1. Fatal errors that mean the script should stop executing, but don't
    actually reflect instability in the engine.
    2. Throwing exceptions from PHP core.

    It seems to me that #2 is strongly opposed by a lot of people.

    I think most people here sympathize with #1, but it hasn't been important
    enough for anyone to actually do the work, and there hasn't been a proposal
    about how it should be done. In general, it requires an audit of every
    E_FATAL error thrown. Some can be changed to E_RECOVERABLE_ERROR. Some
    however, really should kill the script, but don't need to skip error
    handlers. These would need some new E_ constant, and a rule that when
    thrown, an error handler can be called, but the script will die after the
    error handler has finished. There's probably more to it than that, which is
    why there would need to be a RFC. I'm guessing that if someone wrote an
    RFC, and had a patch, it would be received well.

    Thanks,
    John LeSueur

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedJun 17, '12 at 7:06p
activeJun 17, '12 at 9:31p
posts3
users3
websitephp.net

People

Translate

site design / logo © 2019 Grokbase