Re: [RFC] More Appropriate Date/Time Exceptions
| From: | Tim Düsterhus | Date: | Fri, 09 Dec 2022 16:31:02 +0000 |
| Subject: | Re: [RFC] More Appropriate Date/Time Exceptions | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-119105@lists.php.net to get a copy of this message | ||
Hi
On 12/9/22 17:17, Dan Ackroyd wrote:
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üsterhusIf 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.