Stanislav Malyshev wrote on 23/03/2015 05:21:
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.
Thoughts?
I came upon exactly this situation some time ago, and posted to the list
about it: http://marc.info/?l=php-internals&m=138118333112741&w=2
The options I presented there are:
1) Mark all exceptions as non-serializable, as you suggest, removing the
surprise.
2) Don't capture args in exceptions backtraces, with the additional
benefit of destructors firing more predictably.
3) Strip args out of the backtrace when serializing.
4) Have a function to strip the backtrace ready to serialize, and
prevent serialization if it hasn't been called.
Option 1 is the simplest, but just as many have questioned the need to
serialize exceptions, I would question the need for their backtraces to
contain every argument passed to every function in the stack, so would
tend towards option 2. AFAIK, no unserializable information is stored
outside the 'args' element of the backtrace items.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
