Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87464
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.181 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <55BBD2EE.2070008@gmail.com>
References: <550FA2ED.6080000@gmail.com> <CADR=R-gtCy7Vi7Y15jx+SYWX3aEB6TN3WGJPAqqQ4tO__SWqQw@mail.gmail.com> <CAF+90c8c8_Vth3vVaYF1N1u68JANTbGDq-QUTvG44X+Wr+oe0A@mail.gmail.com> <55B7B08E.7070700@gmail.com> <CAH-PCH7Yw8KWZa5oLguUjD2-3DrSsH0Kb7cO9yLKYy4UNETWCQ@mail.gmail.com> <55BBD2EE.2070008@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Fri, 31 Jul 2015 23:20:58 +0100
To: Stanislav Malyshev <smalyshev@gmail.com>
CC: PHP Internals <internals@lists.php.net>
Message-ID: <B0DD7401-6FCA-41E5-AC24-B5C273CED742@gmail.com>
Subject: Re: [PHP-DEV] Re: Serializing exceptions
From: rowan.collins@gmail.com (Rowan Collins)

On 31 July 2015 20:56:30 BST, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>Hi!
>
>> Personally I feel the restoring them impossible argument weak,
>consider
>> that we allow stuff like serializing resources without even a notice.
>
>Not sure what you mean by that. If you try to serialize resource, you
>just get an integer. Not ideal, as a remanant of the times in PHP where
>the approach was "if it doesn't make sense, do whatever and hope the
>user is ok with that", but certainly it's not "serializing resources".
>It's "ignoring resources when serializing and producing integers
>instead". Replacing Exceptions with integers probably won't work that
>well :)
>
>> Based on my own experiences where I had to fix multiple apps when we
>> introduced the unserializable Closure (mostly error logger and
>debugging
>> tools) which got passed as argument in the backtrace I would prefer
>if
>> we could remove that restriction.
>
>I don't see how we can really remove the underlying problem -
>Exceptions
>contain backtraces, which means serializing them tries to serialize a
>ton of stuff that may be not only not serializable but outright
>dangerous

As I have pointed out several times, it is only the 'args' section of the backtrace that ever contains unserializable items. The solution is simply not to include that argument - equivalent to setting DEBUG_BACKTRACE_IGNORE_ARGS in a debug_backtrace() call. IIRC the object of called methods is already excluded (equivalent to masking out DEBUG_PROVIDE_OBJECT) so what's left is all strings.

I would have thought that genuine use cases for extracting arbitrary arguments out of an exceptions backtrace would be pretty rare.

Regards,
-- 
Rowan Collins