Re: [RFC DISCUSSION] Error Storage Behavior

On 7/13/2016 10:29 PM, Nikita Popov wrote: > 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 > The thing that bugs me is the fact that I could not find a single situation in which error_get_last() contains a warning although an exception was thrown other than in the DateTime example from the original bug report. I do not want to simply report this as a bug fix without fully understanding its implications. In other words: why does error_get_last() sometimes contain a warning and sometimes doesn't?!? This is why I opened this thread, to get some insights from you guys since you know internals much better. -- Richard "Fleshgrinder" Fussenegger

Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc