Re: [RFC DISCUSSION] Error Storage Behavior

From: Date: Wed, 13 Jul 2016 20:29:05 +0000
Subject: Re: [RFC DISCUSSION] Error Storage Behavior
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-94503@lists.php.net to get a copy of this message
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

« previous php.internals (#94503) next »