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é
