Error handling brainstorming

Andrew:
From your mails, it seems that you don't agree with Stan on turning
everything but fatals into exceptions[9].
I'm really confused about that, as if we take away warnings (and by
that logic everything else which is less serious than a warning) the
we would only have the fatal errors (which we already discussed to not
turn into exceptions and you also seemed to agree[10]), E_USER
and E_RECOVERABLE_ERROR.
Is this what you propose?
Warnings aren't "errors" as such (IMO they are little more than
glorified debugging print statements). Making them into exceptions would
mean you'd have to catch them, whilst at the moment they are loud but
harmless.
However, I think more serious errors should be exceptions. But perhaps
in PHP 6, because obviously this would break a lot of things.

My opinion (and this is what I tried to explain to you) is that it is
pretty common in the core and the bundled extensions to raise notices
and warnings left and right, and still do something,
By that I thought you meant errors of the kind E_STRICT, not warnings.
Misunderstanding.
If we would turn anything less serious than E_RECOVERABLE_ERROR (so
any notice, deprecation notice, strict notice or warning)into an
exception, that would be a huuuuuuge BC break.
Of course. I think they are something the current errors system should
remain for. It should be for that kind of thing, but proper "errors"
(you know, things going wrong, not warnings etc.) should be exceptions,
I think.
Basically silecing errors through setting error_reporting level,
custom error handlers or the @ operator would stop working, and one
should put everything into a try-catch block to not have his code
blown into his code constantly.
Another thing that I mentioned: even if you catch everything, there
would be some things that you couldn't do anymore.
Any method which throws notices or strict/deprecated notices or
warnings would be broken, as the execution would be halted (as the
execution jumps into the catch) which would be a major PITA to the
userland developers, and without further work, it could make the
userland/engine in a more fragile state, as the original call was
interrupted but the execution still continues from a different spot.
With the current error handling the execution either resumes after the
error handler is called, or the execution is terminates gracefully

The current error handling provides a way to trigger multiple
errors/warnings for an operation, and allows to still return and
continue the execution.
Turning everything into exceptions would kill both of those, and
without providing something similar suite, we can't do that imo.

So basically these are our boundaries:

• Fatal errors can't be turned into Exceptions, but it was mentioned
  multiple times, that there are some fatals, which could be turned
  into E_RECOVERABLE_ERROR.

Truly fatal errors can't become exceptions. But some fatal errors
shouldn't be fatal and are recoverable (and I think these should become
exceptions).

• Most/all non-fatal errors could be safe to be turned into
  Exceptions as without explicit measures(try-catch) on the caller's
  side, it would still stop the execution.
• Every other warning/notice/etc. which are just holds additional
  information but not indicating unsuccessful execution in itself
  cannot be turned into Exceptions.

I have a few ideas about how to proceed from here, but I need some
time to gather my thoughts.

1. internals@lists.php.net/msg60043.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg60043.html
2. internals@lists.php.net/msg60054.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg60054.html
3. internals@lists.php.net/msg60056.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg60056.html
4. https://wiki.php.net/rfc/errors_as_exceptions
5. https://wiki.php.net/rfc/enhanced_error_handling
6. internals@lists.php.net/msg60060.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg60060.html
7. internals@lists.php.net/msg60063.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg60063.html
8. http://www.php.net/manual/en/errorfunc.constants.php
9. internals@lists.php.net/msg60061.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg60061.html
10. internals@lists.php.net/msg60065.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg60065.html

To sum up my thoughts:

• "real" (i.e., things going wrong, code doing something bad) errors
  should become exceptions, with the possible exception of fatal errors
  that it is impossible to recover from
• notices, warnings, deprecations, etc. should stay as PHP errors, so
  you can just suppress them if you want, and they don't require you to
  handle them

So fatal errors and notices/warnings/deprecations stay errors,
everything else becomes an exception.

Clear?

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

--
Andrew Faulds
http://ajf.me/

Hi,

We started a discussion about the current error handling mechanism and the
possible improvements in the "Why do disabled functions / classes generate
a WARNING" thread[1], but that is a little bit offtopic there, so I decided
to create a separate thread for it.

I think there are several types of errors in PHP that have to be
handled differently:

• There are "debugging" class errors, like notices etc. They are
  normally programming mistakes, but don't really prevent further
  execution of the script. Those should stay as they are. Throwing
  exceptions here would make things more complicated for the caller.
• There are real errors, which should actually stop execution, but
  which currently don't because throwing a fatal error would be overkill
  due to it's incatchability (and even recoverable fatals are hard to
  catch). Many warnings fall into this category. E.g. if a function is
  called with incorrect parameters (e.g. too little of them) then an
  E_WARNING is thrown. The wrong function call is clearly an error, but
  PHP chooses to continue execution there. In my eyes this is a mistake
  and these cases should be exceptions. (As exceptions are easily
  catchable one can combine the best of both worlds here).
• There is a small number of recoverable fatal errors. Those are
  obviously the clearest candidates for exceptions, because recoverable
  fatal is basically an exception with very ugly catching.
• There are a large number of fatal errors in places which aren't
  really fatal. They probably should be recoverable fatals now, and as
  such exceptions in the future.
• There is a small number of truly fatal errors, i.e. some kind of
  problem deep in the engine. There is probably no way to turn those
  into exceptions.
• Another special category are parse and compilations errors. Those
  are not inherently fatal (e.g. a parse error in an eval() does not
  have to stop script execution), but they would be really hard to turn
  into exceptions with the current architecture.

To summarize, what I'd like to see:

• Not-really fatal errors (and currently recoverable fatal errors) to
  be converted into exceptions
• Some of the warnings be converted to exceptions (depends on the
  exact context).
• Leave notices etc alone.

Nikita

Hi,

having worked on the user land side of error handling
[1]https://github.com/nicolas-grekas/Patchwork-Logger/blob/master/class/Patchwork/PHP/ErrorHandler.php,
I wanted to share some more ideas that could help enhance the current error
handling mechanism.

Concerning throwing vs not throwing exceptions, the current error handling
mechanism allows everyone to code what they prefer, thanks to custom error
handling. Personally, I always throw on E_RECOVERABLE_ERROR and
E_USER_ERROR. I've found that it's the only safe and compatible choice if I
want to reuse some code from others, like a PEAR lib for example, while
allowing to recover from situations that otherwise halt script's execution.

The really cool thing about error handling in PHP is that we can customize
it quite extensively. The bad thing is that we can't customize the behavior
for non-catchable errors (E_ERROR, E_CORE_ERROR, E_COMPILE_ERROR, E_PARSE,
E_CORE_WARNING and E_COMPILE_WARNING). Of course, I understand that the PHP
engine can't be made to recover from all errors. But my feeling is that
some which are currently fatal could be made recoverable
[2]https://bugs.php.net/bug.php?id=55428.
It would be awesome if as much E_ERROR as possible could be converted to
E_RECOVERABLE_ERROR! As a side note for E_PARSE: it is fatal, but only when
including and not when inside an eval(). This dual E_PARSE behavior is
strange, and I wonder if "E_PARSE when including" could be made
E_RECOVERABLE_ERROR? Then, could also "E_PARSE when eval()" be made
user-catchable?

The second idea I wanted to share concerns error silencing. The @ operator
can sometimes make debugging a nightmare, especially when the error it
hides is one of the non-catchable ones. I know about xdebug.scream, but it
works by removing @s, so it makes impossible to differentiate between
"would be silenced" and "is not silenced" errors and as such it can't be
enabled all the time. On my side, to work around silencing, I use a custom
error handler [1]https://github.com/nicolas-grekas/Patchwork-Logger/blob/master/class/Patchwork/PHP/ErrorHandler.phpfor
catchable errors, and some special code [3] around includes. In my
error handler, I use a bit field to configure a set of error levels that
are never silenced. The hack [3] for non-catchable errors works, but needs
special care. A more general approach would be to add a "minimal error
reporting level" or otherwise named "screamed errors" bit field in PHP
core. Would this be possible? Is it a good idea?

Then comes the third idea I wanted to share: to me, the last area where PHP
doesn't help debugging is at shutdown time, with the "Exception thrown
without a stack frame in Unknown on line 0" error. Before shutdown time,
uncaught exceptions are transfered to the exception handler (php default or
user callback). But at shutdown time, this cryptic error message is always
reported instead. I know that shutdown time is very special and code
running there should be kept rare, but it happens... So, could we get rid
of this cryptic error message, and replace it with the regular exception
handling path? I tried and somewhat managed to enhance the situation user
land side: if you replace every single call to register_shutdown_function()
with [4], and every single __destruct() with [5], then this fixes most of
the pb. AFAIK, the only other case where an uncaught exception could be
triggered is in a remaining output buffering handler. But as in [4], it
wouldn't be hard to encapsulate output buffering handlers in a catching
closure. As it looks possible in user land, is the same doable on the
engine side?

I'm over with my ideas, thanks for reading :)

Nicolas

[1]
https://github.com/nicolas-grekas/Patchwork-Logger/blob/master/class/Patchwork/PHP/ErrorHandler.phphttps://github.com/nicolas-grekas/Patchwork-Logger/blob/master/class/Patchwork/PHP/ErrorHandler.php
[2] https://bugs.php.net/bug.php?id=55428https://bugs.php.net/bug.php?id=55428

[3] :

<?php

$error_level_bak = error_reporting(error_reporting() | E_PARSE | E_ERROR |
E_CORE_ERROR | E_COMPILE_ERROR);
include $file;
error_reporting($error_level_bak);

?>

[4] :
<?php

function my_register_shutdown_function($callback)
{
$args = func_get_args();

$callback = function() use (&$args)
{
    try
    {
        call_user_func_array(array_shift($args), $args);
    }
    catch (\Exception $e)
    {
        $h = set_exception_handler('var_dump');

// "var_dump" is never used as per the next line
restore_exception_handler();
if (null !== $h) call_user_func($h, $e);
else user_error("Uncaught exception '" . get_class($e) . "' in {
$e->getFile()} on line {$e->getLine()}", E_USER_WARNING);
exit(255);
}
}

return register_shutdown_function($callback);

}

?>

[5] :

<?php

class foo
{
function __destruct()
{
try
{
// destructor's implementation here
}
catch (\Exception $e)
{
unset($t);

        if (empty($e->isDestructorException))
        {
            $t = array_slice($e->getTrace(), -1);

            if (isset($t[0]['line']) || !isset($t[0]['class']) ||

strcasecmp('__destruct', $t[0]['function']))
{
$e->isDestructorException = 1;
}
else
{

// This code path is taken only when the $e exception has been
// thrown while PHP was calling remaining objects'
destructors,
// at the very end of script's execution.
$e->isDestructorException = $t[0]['class'];
}
}

        if (isset($e->isDestructorException) && __CLASS__ === $e->

isDestructorException && 1 === count(debug_backtrace(
DEBUG_BACKTRACE_IGNORE_ARGS, 2)))
{
$t = set_exception_handler('var_dump');
// "var_dump" is never used as per the next line
restore_exception_handler();

            if (null !== $t) call_user_func($t, $e);
            else user_error("Uncaught exception '" . get_class($e) .

"' in {$e->getFile()} on line {$e->getLine()}", E_USER_WARNING);
exit(255);
}

        throw $e;
    }
}

}

?

Hi!

Basically Etienne mentioned that the original issue was a good example why
would we reconsider throwing exceptions from the core, which is currently
discouraged.[2]
Stan replied with the idea of turning the current error handling mechanism
in php into using Exceptions for everything, but keeping some error types
as is/uncatchable. [3]

Exceptions are different from PHP errors. For example, if you try to
open a file and the file isn't there, throwing exception is a very
annoying behavior (yes I know some languages do that, IMO it's wrong).
The reason is that it's pretty normal and within normal set of
situations to which code should be prepared, so you will either have to
obsessively wrap everything with try/catch blocks or do exception typing
like Java does. Both options are quite annoying. I think it's much
better to just open file and check if the result is OK. Converting it to
exception doesn't really improve situation, as if downstream code didn't
handle it the upstream probably won't know what to do with that
exception either. This leads to code like try { whatever(); }
catch(Exception e) {}. I saw tons of that in Java.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Basically Etienne mentioned that the original issue was a good example why
would we reconsider throwing exceptions from the core, which is currently
discouraged.[2]
Stan replied with the idea of turning the current error handling mechanism
in php into using Exceptions for everything, but keeping some error types
as is/uncatchable. [3]

This is going to be the biggest BC break ever. Instead of harmless
notices and warnings that people will and can (and sometimes should)
ignore, the moment any of those happens, the script will suddendly
because the exception isn't caught.

Andrew:
From your mails, it seems that you don't agree with Stan on turning
everything but fatals into exceptions[9].

That's a funny one. The only thing that currently makes sense to use an
exception for is the E_RECOVERABLE - that is, without potentionally
breaking any script that's ever been written.

So basically these are our boundaries:

• Fatal errors can't be turned into Exceptions, but it was mentioned
  multiple times, that there are some fatals, which could be turned into
  E_RECOVERABLE_ERROR.

Some, but definitely not many. When we introduced E_RECOVERABLE we had a
good look at them all.

• Most/all non-fatal errors could be safe to be turned into Exceptions
  as without explicit measures(try-catch) on the caller's side, it would
  still stop the execution.

And hence break the script...

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

Hi!

Personally, I'm used to what other languages like Python do, and I think
it makes more sense. Exceptions mean you can try/catch the things your
code needs to be prepared for (non-existence, maybe), but other things
No, they mean you need to always try/catch since you have to means to
check if the downstream function can throw and exception or maybe call
some other function that throws and exception. Exceptions propagate. In
Java, you have compiler-controlled throws (which doesn't work in 100% of
cases either - I regularly get exception messages from Eclipse, and this
one is written by people with great knowledge of Java) - in PHP, you
will have nothing. It's one thing when the code writes a warning and
returns null when something unexpected happens, another when it throws
and exception and you have to know which kind it will be and catch it

• or just catch everything and ignore it (because you have no idea what
  it might be) and - check some success value then!
  Why do you have to always try/catch? You're making the assumption you
  need to check for and catch every error. You don't, unless you're
  working with something like networking. Exceptions mean that an
  exception, an error that infrequently pops up, but occasionally enough
  that it matters, can be caught and dealt with. Other ones you don't have
  to account for, because execution will just stop right there. You don't
  need to bother checking the return value.

you haven't considered or are very unlikely, can just not be caught and
cause your code to halt execution. And it makes it harder to
accidentally avoid checking for errors and then wonder why $file is some
NULL or FALSE or other "error" value.
How it makes it harder? If you forget to check the result, you'll as
well forget to try/catch. It just makes the consequences worse - and
remember, this all happens in runtime!
With exceptions, your code stops running then and there. Without them,
with an unchecked return value, your code keeps going until it does
something stupid, which can be quite irritating to debug.

--
Andrew Faulds
http://ajf.me/