Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:87458 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 1662 invoked from network); 31 Jul 2015 20:22:50 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 31 Jul 2015 20:22:50 -0000 X-Host-Fingerprint: 68.118.157.39 68-118-157-39.dhcp.mdsn.wi.charter.com Received: from [68.118.157.39] ([68.118.157.39:22971] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id BB/62-24609-919DBB55 for ; Fri, 31 Jul 2015 16:22:50 -0400 Message-ID: To: internals@lists.php.net Date: Fri, 31 Jul 2015 15:22:46 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 References: <550FA2ED.6080000@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 68.118.157.39 Subject: Re: Serializing exceptions From: me@stephencoakley.com (Stephen Coakley) 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