Re: [Vote] More Appropriate Date/Time Exceptions

On Fri, Dec 16, 2022 at 5:09 PM Derick Rethans <derick@php.net> wrote: >On 16 December 2022 21:34:16 GMT, Theodore Brown <theodorejb@outlook.com> wrote: >>On Thu, Dec 15, 2022 at 8:27 AM Derick Rethans <derick@php.net> wrote: >> >>> Hi, >>> >>> I've just opened the vote for "More Appropriate Date/Time Exceptions". >>> It runs until December 31st, 24:00 UTC. >>> >>> You can vote at: >>> https://wiki.php.net/rfc/datetime-exceptions#voting >> >> Hi Derick, >> >> Thank you for your work on this. I like the idea of having more specific >> exceptions to avoid having to parse generic exception/warning strings. >> >> However, I voted No because there doesn't seem to be an implementation >> currently, and I'm concerned about introducing differences in error >> handling between the procedural and object-oriented date functions. >> >> Is there a rational for why the procedural date functions should continue >> producing generic warnings/exceptions, rather than consistently using the >> same exception hierarchy as the OO interface? I fear this could make it >> harder for users to switch between the procedural and OO APIs, as some >> errors might have to be handled in a different way. >> >> Also, could maintaining parity between the procedural/OO APIs be more >> difficult if they each implement error handling differently? >> Perhaps I'm mistaken, but I thought that currently the procedural date >> functions are simple aliases of the corresponding object method. > > You're mistaken then. The procedural versions never threw exceptions, > and changing to that now is a big BC break, which is not warranted. > > It was always a deliberate choice (since 2014) that the procedural > versions don't throw exceptions, and the OO versions do. The RFC is not > wanting to change this behaviour. And rightfully so. Thank you for the clarification. I know that the functions date_create and date_create_immutable have this difference in behavior from the DateTime and DateTimeImmutable constructors, and this is documented in the PHP manual. But for most other date functions there doesn't seem to be any difference. E.g. date_create_from_format and DateTime::createFromFormat both return false on failure. Likewise, date_interval_create_from_date_string and DateInterval::createFromDateString both output a warning and return false on failure, as do date_modify and DateTime::modify. See https://3v4l.org/HjXee. So I'm struggling to understand why it's okay to make a BC break for the OO API, but not for the procedural API. As long as a BC break is being made, why not change date_create and date_create_immutable throw exceptions like the constructors, rather than trying to preserve BC for only the procedural API and ending up with even more inconsistent behavior? Best regards, Theodore