|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #70429 unserialize() should trigger an exception instead of error
Submitted: 2015-09-04 14:07 UTC Modified: 2017-08-05 04:48 UTC
Avg. Score:3.0 ± 2.0
Reproduced:1 of 2 (50.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: david dot proweb at gmail dot com Assigned:
Status: Suspended Package: Scripting Engine problem
PHP Version: Next Minor Version OS:
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2015-09-04 14:07 UTC] david dot proweb at gmail dot com
It can be solved with the error control operator, but seems bad. In general terms, we can consider throws an exception. So it can be handled in correct way. But we have others options.

0. Currently:

    $data = @unserialize($serialized);

  Good: very simple;
  Bad: no real error control, why it failed?

1. Exception:

    try { $data = unserialize($serialized); }
    catch (Exception $e) { ... }

  Good: it can be catched;
  Bad: it can cause breaking changes (requires major version upgrade);

2. Return false:

    $data = unserialize('invalid');
    $data === false;

  Good: simple way to catch;
  Bad: it can be confused with a valid serialize(false);
  └ But: it should not be a problem, currently you have not a error control for that;

3. Set reference parameter in case of error:

    $data = unserialize('invalid', $options, $error);
    if (!$error) { ... }

  Good: not too good, but should avoid the previous problem;
  Bad: it'll be the third parameter (PHP7 implements $options as 2nd);

4. Add a new option to choice between solutions1, 2 and maybe 3, and current mode:

    $data = unserialize('invalid', [ 
        'errorMode' => PHP_UNSERIALIZE_ERROR,     // default/current
        'errorMode' => PHP_UNSERIALIZE_EXCEPTION, // solution 1
        'errorMode' => PHP_UNSERIALIZE_FALSE,     // solution 2
        'errorMode' => PHP_UNSERIALIZE_PARAM,     // solution 3

        // This should set the error to this reference.
        // If errorMode is not set, it'll change it to PHP_UNSERIALIZE_PARAM.
        // If errorMode is different of PHP_UNSERIALIZE_PARAM and it is set, errorMode is prioritized.
        'errorReference' => &$error,

  Good: it's flexible;
  Bad: not too bad, but seems no much efficient;

5. Create a new function to check first if serialized is valid:

    $data = null;
    if (is_serialized($data)) {
        $data = unserialize($data);

  Good: is more intuitive;
  Bad: is more exhaustive to code and to process;
  └ But: on call is_serialized() the $data should be parsed. 
         It can be processed too and reutilized by unserialize(), that *generally* should be called after validate.

6. Create a new function that can use one of solutions here (1, 2, maybe 3 and 4):

    $data = serialize_decode('invalid');       // Exception, false, ...
    $data = serialize_decode(serialize(true)); // OK


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2017-08-05 04:48 UTC]
-Status: Open +Status: Suspended
 [2017-08-05 04:48 UTC]
Thank you for your interest in PHP and for submitting a feature request. Please be aware that due to the magnitude of change this request requires, it would be necessary to discuss it on PHP Internals list ( as an RFC. Please read the guide about creating RFCs here:
If you haven't had experience with writing RFCs before, it is advised to seek guidance on the Internals list ( and/or solicit help from one of the experienced developers. 

Please to not consider this comment as a negative view on the merits of your proposal - every proposal which requires changes of certain magnitude, even the very successful and widely supported ones, must be done through the RFC process. This helps make the process predictable, transparent and accessible to all developers.
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Thu Jan 21 19:01:27 2021 UTC