On Sat, 10 Dec 2022 at 10:06, Robert Landers <landers.rob...@gmail.com> wrote:
>
> However, I generally feel that the program will always have access to
> the raw data, after all, it is unserializing it.
Not always in a useful way.
function getMeeting(DB $db, int $meeting_id): Meeting
{
$meeting_data = $db->getUserSettings($meeting_id);
return unserialize($meeting_data);
}
If the $meeting_data included invalid DateTime info, the info wouldn't
be in the stacktrace. Investigating that issue would require someone
manually extracting some data from the production DB, which
programmers shouldn't have direct access to.
Tim Düsterhus wrote:
>
> 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.
When the info isn't completely contained in the exception message
itself, what tickles my fancy is having small functions that format
specific exception types into an easy to understand to comprehend
piece of info, so that no-one has to spend time trying to read a
stack-trace.
> I'm against ext-specific or library-specific exception classes
> for unserialization failures,
Good point.
I'll raise it again when there is another discussion about an
UnserializeException.
Although it would probably be safe to expose invalid data that was
meant to be turned into a DateTime object, it's not obvious that it
would be safe to increase the exposure of arbitrary data, as it might
include PII data.
cheers
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
