Re: Re: [RFC] OOP API for cURL extension
| From: | Tim Düsterhus | Date: | Thu, 15 Feb 2024 20:43:02 +0000 |
| Subject: | Re: Re: [RFC] OOP API for cURL extension | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-122393@lists.php.net to get a copy of this message | ||
Hi
On 2/15/24 16:44, Sara Golemon wrote:
* Define the conditions under which exceptions will be thrown (and which exceptions) - I'll add these to the RFC, but in short: * CurlException - Never, it's an interface type to group the other exceptions.Interface or base Exception? I would suggest base exception for consistency with \Random\RandomException and \DateException and because of the reasoning I gave in this PR: https://github.com/php/php-src/pull/9220
* CurlHandleException - Whenever a CurlHandle::method() fails (in lieu of returning false) * CurlMultiException - Same, but for the CurlMultiHandle class. * CurlShareException - Same, but for the CurlShareHandle class.You already said that you would clarify, but I'm not sure if I find the distinction between Handle/Multi/Share useful. An invalid option being passed to curl_setopt() and curl_multi_setopt() is an invalid option in both cases. No need to differentiate the exception type, because you know what function you called. In fact it should probably be a ValueError and not even something ext/curl-specific. Likewise a connection failure would be a connection failure, no matter if it is emitted by a handle or a multihandle: This could be a CurlConnectException (or possible a namespaced Curl\ConnectException). Best regards Tim Düsterhus