Re: [PHP-DEV] [RFC] More Appropriate Date/Time Exceptions

2022-12-19 Thread Dan Ackroyd
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

Re: [PHP-DEV] [RFC] More Appropriate Date/Time Exceptions

2022-12-15 Thread Derick Rethans
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

Re: [PHP-DEV] [RFC] More Appropriate Date/Time Exceptions

2022-12-10 Thread Robert Landers
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

Re: [PHP-DEV] [RFC] More Appropriate Date/Time Exceptions

2022-12-09 Thread Tim Düsterhus
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

Re: [PHP-DEV] [RFC] More Appropriate Date/Time Exceptions

2022-12-09 Thread Dan Ackroyd
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

Re: [PHP-DEV] [RFC] More Appropriate Date/Time Exceptions

2022-12-08 Thread Tim Düsterhus
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

Re: [PHP-DEV] [RFC] More Appropriate Date/Time Exceptions

2022-12-08 Thread Dan Ackroyd
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

Re: [PHP-DEV] [RFC] More Appropriate Date/Time Exceptions

2022-12-07 Thread Derick Rethans
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

Re: [PHP-DEV] [RFC] More Appropriate Date/Time Exceptions

2022-11-29 Thread Michał Marcin Brzuchalski
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.