rfc:datetime-exceptions

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Last revisionBoth sides next revision
rfc:datetime-exceptions [2022/11/29 17:37] – formatting derickrfc:datetime-exceptions [2023/01/04 20:29] – Move to accepted ilutov
Line 1: Line 1:
 ====== 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
  
Line 11: Line 11:
 This RFC proposes to introduce Date/Time extension specific exceptions and errors where this makes sense. This RFC proposes to introduce Date/Time extension specific exceptions and errors where this makes sense.
  
-Right now, they are either warnings/errors, or plain "Exception" or "Error". This does not allow for catching Date/Time extensions 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:
Line 35: Line 36:
   * 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"''
Line 79: Line 80:
         * ''"%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.
Line 102: Line 102:
 ===== 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 foror against.+To accept this RFCand 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 =====
Line 123: Line 130:
 None yet. None yet.
  
-===== Proposed PHP Version(s) =====+===== ChangeLog =====
  
-Next PHP 8.x.+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''.
  
-===== RFC Impact ===== 
- 
-No impact to any other extensions or opcode. 
- 
-===== Open Issues ===== 
- 
-There are currently no open issues. 
- 
-===== 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. 
- 
-===== Proposed Voting Choices ===== 
- 
-Either for, or against. 
- 
-===== Patches and Tests ===== 
- 
-There is no patch yet. 
- 
-===== Implementation ===== 
-After the project is implemented, this section should contain  
-  - the version(s) it was merged into 
-  - a link to the git commit(s) 
-  - a link to the PHP manual entry for the feature 
-  - a link to the language specification section (if any) 
- 
-===== Rejected Features ===== 
- 
-None yet. 
rfc/datetime-exceptions.txt · Last modified: 2023/02/08 10:43 by derick