On 07/27/2015 02:08 AM, Stas Malyshev wrote:
Hi!
Looking into some issue, I've discovered that, to my surprise,
Exceptions are serializable. Except that it doesn't always work of
course (e.g. see http://stackoverflow.com/q/9747813/214196) because
exceptions contain backtraces, and those can contain non-serializable
objects. So in reality, you never know if you can serialize it or not.
So, I wonder - would it be ok to make exceptions not serializable at
all? I think that would prevent major WTF factor when people try it and
it randomly fails.
Since discussion on this did not lead to a definite conclusion, but I did
not hear from anybody that they need serialized exceptions, and we keep
getting bug reports about exception serialization and various issues
triggered by it, I propose this change:
https://github.com/php/php-src/pull/1442
Since it is kind of BC break (even though I assume it breaks something that
needed not to be allowed in the first place) I'd like to merge it in 7.0.0.
Please object if you think this should not be done and explain why.
Otherwise I intend to merge it after a suitable wait and after adding
necessary tests/docs.
Thanks,
I'm serializing exceptions in a current project, and I would much prefer
losing `args` (the only part not always serializable) from the trace
than not being able to serialize the exception at all.
Making exceptions not serializable will just result in another userland
wrapper, like a SuperException, that lets you serialize and unserialize
with eval()'s. I think allowing the serialize to drop args in the trace
and just include a warning in the docs about the serialization being lossy.
My 2 cents.
--
Stephen Coakley
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
