Re: HTTP_Request2 heads up: cookie jar and exception hierarchy

Hi, On 19.02.2011 16:49, Alexey Borzov wrote:

I suspect that many people on this list are using HTTP_Request2, so I'd like to get some feedback on granularity of error codes / exceptions they need. There is currently a patch [3] attached to the request, but it basically assigns a unique error code for each message or passes the code from underlying extension so it doesn't solve anything IMO. For exception hierarchy I see roughly the following: - pilot errors - missing data, passing junk to methods - configuration errors (trying to use Curl Adapter without curl enabled; trying to decode gzip/deflate encoded response without gzip) - network errors - connection error: unknown host, connection timeout, SSL validation failure... - request timeout - response errors - protocol error: non-HTTP response, broken encoding - redirect error: redirect to non-HTTP protocol, maximum number of redirects exceeded Are there any exception subclasses that are needed but are not present in the above list? If some exception hierarchy is done, then is there a need for some additional error codes (or should we just repackage error codes returned by curl / socket)?

I see that people pay more attention to stuff already implemented (cookie jar) rather than to stuff that needs implementation. That's understandable, but I'd still like to get some feedback about exceptions. :] Here is a more refined idea: HTTP_Request2_Exception |- HTTP_Request2_NotImplementedException |- HTTP_Request2_LogicException |- HTTP_Request2_ConnectionException \- HTTP_Request2_MessageException NotImplementedException will be thrown for features that are not implemented (duh). LogicException will be thrown for pilot errors / PHP misconfigurations. Usually before request will even start. It is possible to add granularity here (wrong parameters / missing parameters / misconfiguration) ConnectionException will be thrown on failure to connect to a remote server. It is quite difficult to add granularity here, since stream_socket_client() used by Socket Adapter returns error codes provided by OS / other libraries like OpenSSL. MessageException will be thrown for errors that happen after connection is established. It is possible to add granularity here (we can probably use error codes for that?) Unlike errors from stream_socket_client(), curl_errno() error list is manageable and can be mapped to exception subclasses / error codes. It may make sense to add getNativeCode() method to HTTP_Request2_Exception that will return error codes from stream_socket_client() / curl_errno() rather than return them as part of the error message as is done now.