Hi
Am 2025-02-23 18:30, schrieb Gina P. Banyard:
2.
I don't really understand how the UninitializedUriException exception can be thrown?
Is it somehow possible to create an instance of a URI without initializing it?
It's mentioned in the RFC (it was not yet, when I read through the RFC):
This can happen for example when the object is instantiated via ReflectionClass::newInstanceWithoutConstructor()).
Incidentally this is *also* something that would be fixed by making the classes final, since it's illegal to bypass the constructor for final internal classes:
<?php
$r = new ReflectionClass(Random\Engine\Mt19937::class);
$r->newInstanceWithoutConstructor();
results in:
Fatal error: Uncaught ReflectionException: Class Random\Engine\Mt19937 is an internal class marked as final that cannot be instantiated without invoking its constructor
This seems unwise in general.
I agree. This exception is not really actionable by the user and more of a “should never happen” case. It should be prevented from appearing.
The same is true for UriOperationException. The RFC says that it can happen for memory issues. Can this actually happen? My understanding is that the engine bails out when an allocation fails. In any case if a more graceful handling is desired it should be some generic OutOfMemoryError rather than an extension-specific exception.
With regard to unserialization, let me refer to: https://externals.io/message/118311. ext/random uses \Exception and I suggest ext/uri to do the same. This should also be handled in a consistent way across extensions, e.g. by reproposing https://wiki.php.net/rfc/improve_unserialize_error_handling.
And with “Theoretically, URI component reading may also trigger this exception” being a theoretical issue only, the UriOperationException is not actually necessary at all.
3.
I'm not really convinced by using the constructor to be able to create a URI object.
I think it would be better for it to be private/throwing and have two static constructor parse and tryParse,
mimicking the API that exists for creating an instance of a backed enum from a scalar.
enums are little different in that they are a singleton. The Dom\HTMLDocument class with only named constructors might be a better comparison. But I don't have a strong opinion on constructor vs named constructor here.
Best regards
Tim Düsterhus