Re: What type of Exception to use for unserialize() failure?
| From: | Tim Düsterhus | Date: | Sat, 27 Aug 2022 13:00:30 +0000 |
| Subject: | Re: What type of Exception to use for unserialize() failure? | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-118530@lists.php.net to get a copy of this message | ||
Hi
On 8/27/22 00:17, Rowan Tommins wrote:
While this is technically correct, I am not sure if there is actually a case where a script that is behaving correctly for the current version will break (i.e. everything that will break is already subtly broken). 1. If you are unserializing only trusted data from a compatible PHP version (compatible PHP version, because the serialization output might differ, e.g. for 'C:' and 'O:'), then unserialize() should not fail / not emit any notices or warnings. 2. If you are not in the situation of (1), then unserialize() might already throw arbitrary Throwables for *some* of the inputs, as the implementation of- I've noticed that 'unserialize()' already emits E_WARNING for some types of error (e.g. out-of-bounds integers), so users already need to be prepared for E_WARNING to be emitted. I've adjusted the aforementioned Notice to Warning, but we might be able to directly jump to UnserializationFailedException from the existing warnings?IMHO, any change from Warning or lower to Exception or Error is a clear Breaking Change, because it can make a program that runs successfully under one version abort mid-process in another.
__unserialize() or __wakeup() might throw:
https://3v4l.org/Fc4dk
Best regards
Tim Düsterhus