[RFC DISCUSSION] Error Storage Behavior

Currently error_get_last() always contains the last error that occurred,
however, this is actually not desired if the last error was an exception
that was caught.

Changing the behaviour of how errors are handled, to depend on what
happens after the error occurs, seems a really bad choice to me.

From https://bugs.php.net/bug.php?id=54043

If you create a custom error handler which converts all PHP errors to exceptions,
catching internal exceptions inline therefore throws another Exception in the custom error handler,

Can you provide a reproduce case for this? The code below has a custom
error handler; it is never called.

It's actually not that clear what problem you are trying to solve here.

Should we treat it as a simple bug fix?

No, I don't think we can. First, wrong behaviour is a design flaw not
a bug, and second it's really not obvious that having weird complex
behaviour would be preferrable.

Any feedback here?

This month you've sent almost 4 emails a day to this list. That is an
incredibly high number for a list that is distributed to thousands of
people. This list would be much better served if there were fewer
emails, that contained more fully thought through proposals.

cheers
Dan

<?php

error_reporting(E_ALL);
set_error_handler('tierErrorHandler');
register_shutdown_function('shutdown');

$time = '9999-11-33'; // invalid
$timeZone = new DateTimeZone('UTC');

try {
$dateTime = new DateTime($time, $timeZone);
} catch (Exception $e) {
var_dump('Exception:', $e->getMessage());
}

echo 'END' . PHP_EOL;

function shutdown()
{
$error = error_get_last();
var_dump('Error ', @$error);
}

function tierErrorHandler($errorNumber, $errorMessage, $errorFile, $errorLine) {
echo "Is this called?" . PHP_EOL;
$message = "Error: [$errorNumber] $errorMessage in file $errorFile
on line $errorLine<br />\n";

throw new \Exception($message);

}

Hi!

Currently error_get_last() always contains the last error that occurred,
however, this is actually not desired if the last error was an exception
that was caught.

https://github.com/php/php-src/pull/1936

I think conditioning warnings on whether exception is caught or not is a
very bad idea. However, having either exception or PHP error and not
producing both (except in the case where uncaught exception becomes
fatal error I guess) may be a good idea, but it needs careful checking
of the implications. In general, old error mechanism and exceptions are
not very good combination, and using them together may be troublesome.

It's definitely not "just a bug fix" - it needs careful check of what
exactly happens when.

This is exactly how I see this situation too and why I mailed the list
while asking for feedback.

I think the actual problem from the bug report is not related to the
provided patch that I updated a bit, the problem is as far as I can tell
within the DateTime::__construct method were the error mode is changed
to E_THROW but upon throwing a warning is generated as well. I had a
look at other implementations that change the mode but they did not
behave the same.

I am not familiar enough with all the code yet to simply point out what
is actually wrong but will definitely invest more time unless somebody
else who knows more does and simply fixes it.

--
Richard "Fleshgrinder" Fussenegger

On Mon, Jun 27, 2016 at 9:53 PM, Stanislav Malyshev smalyshev@gmail.com
wrote:

Hi!

Currently error_get_last() always contains the last error that occurred,
however, this is actually not desired if the last error was an exception
that was caught.

https://github.com/php/php-src/pull/1936

I think conditioning warnings on whether exception is caught or not is a
very bad idea. However, having either exception or PHP error and not
producing both (except in the case where uncaught exception becomes
fatal error I guess) may be a good idea, but it needs careful checking
of the implications. In general, old error mechanism and exceptions are
not very good combination, and using them together may be troublesome.

It's definitely not "just a bug fix" - it needs careful check of what
exactly happens when.

I think there is some confusion about this change because the description
was unclear.

The change is only about EH_THROW handling. EH_THROW is used by
extensions to replace warnings etc with exceptions. Currently the exception
is thrown, but error_get_last() still behaves as if the warning was thrown
instead. Fixing this does seem like a normal bug fix to me. Note that this
does not touch exceptions thrown from error handlers or similar in any way.

Basically the problem is that an extension using zend_throw_exception
directly and an exception throwing through EH_THROW will behave
differently, while there should be no difference.

The part about behavior being dependent on whether you catch the exception
or not: This is true only insofar as an uncaught exception generates a
fatal error and that fatal error is retrievable through error_get_last().
There is no special casing occurring here.

Nikita