On Sat, 10 Dec 2022 at 10:06, Robert Landers 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->getUserSet
On Sat, 10 Dec 2022, Robert Landers wrote:
> On Fri, Dec 9, 2022 at 5:31 PM Tim Düsterhus 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 ho
On Fri, Dec 9, 2022 at 5:31 PM Tim Düsterhus 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
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
On Thu, 8 Dec 2022 at 15:05, Tim Düsterhus 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
Hi
On 12/8/22 15:11, Dan Ackroyd wrote:
None of the 'Invalid serialization' errors tell the programmer who
reads them what is wrong with the data.
Unless the code was written in such a way that the data was in (and
was logged) in the callstack, that would be a bit frustrating as
someone might n
On Tue, 29 Nov 2022 at 17:41, Derick Rethans wrote:
>
> I have just published a new "More Appropriate Date/Time Exceptions" RFC
>
>
> Comments?
>
None of the 'Invalid serialization' errors tell the programmer who
reads them what is wrong with the data.
Unless the code was written in such a way t
Hi,
Is there any other feedback, because otherwise I am just going to open
this for a vote next Tuesday.
cheers,
Derick
On Tue, 29 Nov 2022, Derick Rethans wrote:
> Hi,
>
> I have just published a new "More Appropriate Date/Time Exceptions" RFC
> to sort out the warnings, errors, and already
Hi Derick,
wt., 29 lis 2022, 18:41 użytkownik Derick Rethans napisał:
> Hi,
>
> I have just published a new "More Appropriate Date/Time Exceptions" RFC
> to sort out the warnings, errors, and already existing exceptions and
> errors. There are a few minor BC breaks, of course listed in the RFC.