Hi
On 10/19/22 06:14, Tim Starling wrote:
The example in the RFC was written to be correct for the general
case, without imposing any constraints in the input data.
As I said, if throwing was optional, like in json_decode(), I would be
all for it. I'm just doing a cost/benefit analysis. The common case
should be easy, while the general case should be possible.
As a matter of style, I think PHP's false returns are fine. I don't
think we need to follow Python into making every error an exception.
Let me clarify why unserialize is not really comparable to json_decode:
The unserialize handlers (__unserialize, __wakeup,
Serializable::unserialize()) effectively allow arbitrary (both native
and userland) code to run during unserialize(). This arbitrary code
might or might not throw an Exception.
Thus you already need to be prepared to deal with Exceptions being
thrown in the general case: Whenever you unserialize objects you didn't
write yourself. You don't know if a library introduces a change that
causes any existing long-lived serialized object to become incompatible.
---------
Here's an example I've already sent to the list during the discussion
phase of this RFC: https://3v4l.org/Xsmfu
The readonly class 'Foo' had a private (!) '$a' property in the initial
version. This property was removed in a future version, thus breaking
all serialized versions of it, unless the author makes sure to add an
unserialize handler that handles this gracefully. As a developer you
generally wouldn't consider a change to a private property to be a
breaking API change, making this an unexpected gotcha.
---------
Thus *not setting* "UNSERIALIZE_THROW_ON_ERROR" (or whatever you may
want to call it) *does not* guarantee that unserialize() won't throw.
You need to deal with both Notice/Warning and Exceptions. On the other
hand if the Notice/Warning becomes an Exception in a future version the
error handling is simplified: You only need to deal with Exceptions
(specifically a single type of Exception with this RFC).
Best regards
Tim Düsterhus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
