On Fri, Dec 9, 2022 at 5:31 PM Tim Düsterhus <t...@bastelstu.be> wrote: > > Hi > > On 12/9/22 17:17, Dan Ackroyd wrote: > >> If your data fails to > >> unserialize, the only safe option is to throw it away. > > > > Even given that, you probably want to investigate how it got corrupted > > so that you can stop it from happening again. And doing that would > > rely on being able to see the data that you attempted to unserialize. > > That's fair, but does not require dedicated subclasses. Investigating > corrupted serialization data is not something that can be done > programmatically, instead an actual human has to look at the error > message and possibly stack trace within the error log / within Sentry / > whatever floats your boat. > > I'm not against improving the error messages to more clearly indicate > what part of the serialized data is broken, I'm against ext-specific or > library-specific exception classes for unserialization failures, because > that will lead to assumptions being made that will not hold in the > general case. > > Best regards > Tim Düsterhus > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php >
I feel like the RFC could use a bit more clarity around what "unserialize" means. Are we talking about the literal "unserialize()" function, or are we also talking about unserializing a string into a DateTimeInterface object? I took it to mean the latter, and if the latter, then I think putting the original data in the error object is quite important. It's important for generating user-submitted errors, reading data from a database/cache, or other messages. However, I generally feel that the program will always have access to the raw data, after all, it is unserializing it. If the application/framework/whatever wants to log it, it should be able to do that without PHP's help. -- Rob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
