Re: [RFC DISCUSSION] Error Storage Behavior
| From: | Nikita Popov | 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