Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85424
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.174 as permitted sender)
Message-ID: <550FFAA5.5090004@gmail.com>
Date: Mon, 23 Mar 2015 11:36:05 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <550FA2ED.6080000@gmail.com>
In-Reply-To: <550FA2ED.6080000@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Serializing exceptions
From: rowan.collins@gmail.com (Rowan Collins)

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]