Re: [RFC] More Appropriate Date/Time Exceptions

On Sat, 10 Dec 2022, Robert Landers wrote: > On Fri, Dec 9, 2022 at 5:31 PM Tim Düsterhus <tim@bastelstu.be> wrote: > > > > 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. > > 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. The "Invalid serialiszation data for * object" errors (they are already Error) are used in __set_state and __wakeup — for for both PHP's unserialize (the __wakeup) and when calling __set_state with an array with values. Currently these do not provide any other context, and although that can be expanded, it is not what this RFC set out to do. I would say that improving error/exception/warning messages is out of scope. I am not saying that we shouldn't do it, but not as part of this RFC. I'll reflect it to say so, as well as clarify the serialization messages. cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support Host of PHP Internals News: https://phpinternals.news mastodon: @derickr@phpc.social @xdebug@phpc.social twitter: @derickr and @xdebug