On Fri, Dec 16, 2022 at 5:09 PM Derick Rethans <der...@php.net> wrote: >On 16 December 2022 21:34:16 GMT, Theodore Brown <theodor...@outlook.com> >wrote: >>On Thu, Dec 15, 2022 at 8:27 AM Derick Rethans <der...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
