Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87453
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.44 as permitted sender)
To: Ferenc Kovacs <tyra3l@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>
Cc: Nikita Popov <nikita.ppv@gmail.com>,
 PHP Internals <internals@lists.php.net>
Message-ID: <55BBD2EE.2070008@gmail.com>
Date: Fri, 31 Jul 2015 12:56:30 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <CAH-PCH7Yw8KWZa5oLguUjD2-3DrSsH0Kb7cO9yLKYy4UNETWCQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Serializing exceptions
From: smalyshev@gmail.com (Stanislav Malyshev)

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 to carry around - such as keys, passwords, etc. Given how many
problems we have had with serialization of complex objects lately, and
given that I still see absolutely no practical use of actually
serializing exceptions I would rather remove it and reduce the
vulnerable surface than keep dealing with dozens of issues that continue
to pop up from that.

BTW what you mean by "unserializable Closure"? As far as I know you can
not serialize Closure.

-- 
Stas Malyshev
smalyshev@gmail.com