Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision |
rfc:datetime-exceptions [2022/11/30 00:28] – Fixed typoes and double sections derick | rfc:datetime-exceptions [2023/01/04 20:29] – Move to accepted ilutov |
---|
====== PHP RFC: More Appropriate Date/Time Exceptions ====== | ====== PHP RFC: More Appropriate Date/Time Exceptions ====== |
* Version: 0.9 | * Version: 0.9.1 |
* Date: 2022-11-29 | * Date: 2022-12-15 (First created: 2022-11-29) |
* Author: Derick Rethans <derick@php.net> | * Author: Derick Rethans <derick@php.net> |
* Status: Under Discussion | * Status: Accepted |
* First Published at: http://wiki.php.net/rfc/datetime-exceptions | * First Published at: http://wiki.php.net/rfc/datetime-exceptions |
| |
Right now, they are either warnings/errors, or plain "Exception" or "Error". This does not allow for catching Date/Time exceptions as they are not specific enough. | Right now, they are either warnings/errors, or plain "Exception" or "Error". This does not allow for catching Date/Time exceptions as they are not specific enough. |
| |
| Out of scope of this RFC is changing and improving warning, Error, and Exception messages. |
| |
===== Proposal ===== | ===== Proposal ===== |
| |
The proposals is to reclassify warnings and errors as Exceptions, and introduce Date extension specific exceptions and errors. | The proposal is to reclassify warnings and errors as Exceptions, and introduce Date extension specific exceptions and errors. |
| |
The rationale behind all of these is the following: | The rationale behind all of these is the following: |
* Error | * Error |
* ''"Cannot modify readonly property DatePeriod::$%s"'' | * ''"Cannot modify readonly property DatePeriod::$%s"'' |
* ''"Invalid serialization data for DateTime object"'' | * ''"Invalid serialization data for DateTime object"'' (used with ''__set_state'' and ''__wakeup'') |
* ''"Invalid serialization data for DateTimeImmutable object"'' | * ''"Invalid serialization data for DateTimeImmutable object"'' (used with ''__set_state'' and ''__wakeup'') |
* ''"Invalid serialization data for DateTimeZone object"'' | * ''"Invalid serialization data for DateTimeZone object"'' (used with ''__set_state'' and ''__wakeup'') |
* ''"Invalid serialization data for DatePeriod object"'' | * ''"Invalid serialization data for DatePeriod object"'' (used with ''__set_state'' and ''__wakeup'') |
* ''"Unknown or bad format (%s) at position %d (%c) while unserializing: %s"'' (currently a warning) | * ''"Unknown or bad format (%s) at position %d (%c) while unserializing: %s"'' (currently a warning) |
* ''"Trying to compare uninitialized DateTimeZone objects"'' | * ''"Trying to compare uninitialized DateTimeZone objects"'' |
* ''"%s(): Recurrence count must be greater than 0"'' | * ''"%s(): Recurrence count must be greater than 0"'' |
| |
Procedural style use of date/time functions are not effected, and will continue to use warnings and errors as they currently do. | Procedural style use of date/time functions is not affected, and will continue to use warnings and errors as it currently does. |
| |
===== Backward Incompatible Changes ===== | ===== Backward Incompatible Changes ===== |
| |
- The warning for broken serialisation data becomes a new ''Error'', following in the footsteps of the serialization error RFCs that we have seen. This ought not cause a real concern, as right now you would get a broken DateTime object. | |
- The ''"Epoch doesn't fit in a PHP integer"'' now returns a new ''DateRangeError'' instead of a generic ''ValueError'', which it does not subclass. This is only an issue for 32-bit platforms. | - The ''"Epoch doesn't fit in a PHP integer"'' now returns a new ''DateRangeError'' instead of a generic ''ValueError'', which it does not subclass. This is only an issue for 32-bit platforms. |
- The ''"Only non-special relative time specifications are supported for subtraction"'' warning with ''DateTime::sub()'' and ''date_sub()'' becomes a new ''DateInvalidOperationException''. Leaving this with a warning and a NULL return is not useful behaviour. | - The ''"Only non-special relative time specifications are supported for subtraction"'' warning with ''DateTime::sub()'' and ''date_sub()'' becomes a new ''DateInvalidOperationException''. Leaving this with a warning and a NULL return is not useful behaviour. |
===== Unaffected PHP Functionality ===== | ===== Unaffected PHP Functionality ===== |
| |
Warnings and errors that are currently generated by the procedural versions of the Date/Time functionality is not impacted. Only the Object Orientated interface is. | Warnings and errors that are currently generated by the procedural versions of the Date/Time functionality are not impacted. Only the Object Orientated interface is. |
| |
===== Proposed Voting Choices ===== | ===== Voting ===== |
| |
Either for, or against. | To accept this RFC, and get more appropriate exceptions: |
| |
| <doodle title="More Appropriate Date/Time Exceptions" auth="derick" voteType="single" closed="false" closeon="2023-01-01T00:00:00Z"> |
| * Yes |
| * No |
| </doodle> |
| |
| Vote started December 15th, and runs until December 31st, 24:00 UTC. |
| |
===== Patches and Tests ===== | ===== Patches and Tests ===== |
| |
None yet. | None yet. |
| |
| ===== ChangeLog ===== |
| |
| 0.9.1 |
| * Clarified that changing/improving messages is out of scope |
| * Clarified that the "Invalid serialization data for * object" are used for both PHP's unserialize, as well as ''__set_state''. |
| |