# [Vote] More Appropriate Date/Time Exceptions - Thread: https://externals.io/message/119147 - Original archive: https://news-web.php.net/php.internals/119147 - Started by Derick Rethans on 2022-12-15T14:27:43+00:00 - Messages: 7 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #119147 — Derick Rethans — 2022-12-15T14:27:43+00:00 URL: https://externals.io/message/119147#119147 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 cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support Host of PHP Internals News: https://phpinternals.news mastodon: @derickr@phpc.social @xdebug@phpc.social twitter: @derickr and @xdebug --- ## #119148 — Marco Pivetta — 2022-12-15T14:36:29+00:00 URL: https://externals.io/message/119147#119148 · In reply to: #119147 Hey Derick, > 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 > > cheers, > Derick > > Happy to see this move forward, so I voted YES. In a theoretical patch, I suppose it's possible to refine these types further then? https://github.com/php/php-src/blob/b9cd1cdb4f236b7e336b688b16d58a913f4d5c69/ext/date/php_date.stub.php#L363 Would the stub system be capable of documenting exception types? Greets, Marco Pivetta https://twitter.com/Ocramius https://ocramius.github.io/ --- ## #119166 — Derick Rethans — 2022-12-16T12:49:07+00:00 URL: https://externals.io/message/119147#119166 · In reply to: #119148 > > > > […] > > Happy to see this move forward, so I voted YES. > > In a theoretical patch, I suppose it's possible to refine these types > further then? Yes, that would be possible. As you know, subclassing them wouldn't break BC. Whether there is any use, or scope for it, is to be seen of course. > https://github.com/php/php-src/blob/b9cd1cdb4f236b7e336b688b16d58a913f4d5c69/ext/date/php_date.stub.php#L363 > > Would the stub system be capable of documenting exception types? Yes, they are just classes, after all. The random extension already does this too: https://github.com/php/php-src/blob/b9cd1cdb4f236b7e336b688b16d58a913f4d5c69/ext/random/random.stub.php#L167 cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support Host of PHP Internals News: https://phpinternals.news mastodon: @derickr@phpc.social @xdebug@phpc.social --- ## #119180 — Theodore Brown — 2022-12-16T21:34:16+00:00 URL: https://externals.io/message/119147#119180 · In reply to: #119147 > 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. Best regards, Theodore --- ## #119181 — Derick Rethans — 2022-12-16T23:09:14+00:00 URL: https://externals.io/message/119147#119181 · In reply to: #119180 > > > > […] > >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. cheers Derick --- ## #119185 — Theodore Brown — 2022-12-18T16:47:47+00:00 URL: https://externals.io/message/119147#119185 · In reply to: #119181 > > > […] > > 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 --- ## #119186 — Dan Ackroyd — 2022-12-19T15:05:42+00:00 URL: https://externals.io/message/119147#119186 · In reply to: #119185 > > why it's okay to make a BC break for the OO API, > but not for the procedural API. Because they are different APIs. People who use OO apis are used to handling exceptions and would expect failures in OO code to throw exceptions. That the DateTime OO api isn't currently do so is not conformant to their expectations. People who use the procedural apis of DateTime, or procedural versions of the Intl functionality (e.g. NumberFormatter vs numfmt_format_currency) claim to prefer checking `date_get_last_errors()`, numfmt_get_error_code() etc., rather than have to worry about exceptions. Changing the procedural functions to use exceptions would be a bigger and more controversial change than the one proposed in this RFC. cheers Dan Ack