Skip to content

ext/intl: correct the 8.4.0 Error normalization, it only concerns cloning - #5798

Open
lacatoire wants to merge 1 commit into
php:masterfrom
lacatoire:intl-uninitialized-error
Open

ext/intl: correct the 8.4.0 Error normalization, it only concerns cloning#5798
lacatoire wants to merge 1 commit into
php:masterfrom
lacatoire:intl-uninitialized-error

Conversation

@lacatoire

@lacatoire lacatoire commented Aug 26, 2026

Copy link
Copy Markdown
Member

Only the clone path changed in 8.4.0, so the note is restated accordingly.

Throwing an Error when a method is called on a non-initialized Intl object is not new: the macros doing so date back to 2012 and PHP 8.3 behaves identically (verified on php:8.3 and php:8.4 with intl built in, across Collator, NumberFormatter, MessageFormatter, IntlDateFormatter, IntlCalendar, IntlTimeZone, Spoofchecker, Transliterator, IntlDatePatternGenerator, IntlBreakIterator). Saying the classes always throw is also falsifiable on 8.4: UConverter::convert() returns false, ResourceBundle::get() returns null and Collator::getAttribute() returns -1 on a non-initialized object.

What 8.4.0 changed is the clone handlers, and both of their branches matter:

  • refusing to clone a non-initialized object (Cannot clone uninitialized X)
  • an initialized object whose ICU clone() call fails (Failed to clone X)

Formerly most classes threw a base Exception there, and Spoofchecker raised an uncatchable fatal error, which is the part users actually have to adapt their catch blocks for.

  • reference/intl/book.xml: restate the note
  • appendices/migration84/other-changes.xml: fix the same overstatement in the migration entry, so the two places agree rather than drift

Sources

Change Source
Clone error handling normalized to Error php-src 33f1cf202ef (php-src#14360) - "Normalize cloning error handling behaviour - Always throw a Error exception as we cannot progress from here". Only clone paths and idn.c are touched, no INTL_METHOD_CHECK_STATUS macro.
UPGRADING wording PHP 8.4 section 9, added by cd44826c1af
Error on use predates 8.4 a5d0c1e21b (2012-08-21), f5b421621d (2012-05-31)

@lacatoire lacatoire added the 8.4 label Aug 26, 2026
@lacatoire lacatoire added this to the PHP 8.4 milestone Aug 26, 2026
…ning

Only the clone path changed in 8.4.0. Throwing an Error when a method is
called on a non-initialized Intl object is not new: the macros doing so
date back to 2012 and PHP 8.3 behaves identically. Saying the classes
"always throw" is also falsifiable on 8.4: UConverter::convert() returns
false, ResourceBundle::get() returns null and Collator::getAttribute()
returns -1 on a non-initialized object.

What 8.4.0 changed is the clone handlers, and both of their branches
matter: refusing to clone a non-initialized object, and an initialized
object whose ICU clone() call fails. Formerly most classes threw a base
Exception there, and Spoofchecker raised an uncatchable fatal error.

- reference/intl/book.xml: restate the note accordingly
- appendices/migration84/other-changes.xml: fix the same overstatement in
  the migration entry so both places agree

Sources
- php-src 33f1cf202ef ("ext/intl: Various refactoring", php-src#14360):
  "Normalize cloning error handling behaviour - Always throw a Error
  exception as we cannot progress from here". Only clone paths and idn.c
  are touched, no INTL_METHOD_CHECK_STATUS macro.
- UPGRADING (PHP 8.4) section 9, added by cd44826c1af
- Pre-existing Error on use: a5d0c1e21b (2012-08-21), f5b421621d (2012-05-31)
@lacatoire
lacatoire force-pushed the intl-uninitialized-error branch from 6f09f8b to be9fb1b Compare August 26, 2026 09:32
@lacatoire lacatoire changed the title ext/intl: Note Error thrown for non-initialized objects or failed clone (8.4.0) ext/intl: correct the 8.4.0 Error normalization, it only concerns cloning Aug 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant