Hi Tim,
> 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.
>
After checking the code of emalloc et al. I agree with you, the exception
won't actually
be thrown for memory errors. Therefore, I removed this part of the RFC.
>
> 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.
>
Thanks for bringing this RFC to my attention, I agree with the motivation,
so I
changed this aspect of the RFC too to throw an \Exception.
>
> And with “Theoretically, URI component reading may also trigger this
> exception” being a theoretical issue only, the UriOperationException
> is not actually necessary at all.
>
I wanted to reserve the right for any 3rd party internal URI implementations
to fail for whatever reason that prevents reading. The built-in
implementations
don't fail for sure, but it doesn't mean that 3rd party implementations
neither will.
Since potential errors can be handled in some way, I think it makes sense
to keep this exception, especially because it's now basically
non-triggerable.
I'm not sure if I'm entirely correct, but it's possible that a 3rd party
URI implementation
won't (or cannot) use PHP's memory manager, and it relies on the regular
malloc:
in this case, even memory errors could lead to failures.
Regards,
Máté