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
