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
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#votingcheers,
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?
Would the stub system be capable of documenting exception types?
Greets,
Marco Pivetta
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#votingHappy 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.
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
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
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#votingHi 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
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#votingHi 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
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