Description: ------------ When an HTTP_Request2_Exception is thrown, it should contain an errorcode together with a constant mapping to that errorcode so that it is possible to handle the problem without having a user looking at it. Test script: --------------- try { sendSomeRequest(); } catch (HTTP_Request2_Exception $e) { if ($e->getCode() == HTTP_Request2::TIMEOUT) { // resend request } }

I dunno - how much point is there having an exception with a decent, informative message so you can print $e->getMessage() it and understand the error; if everyone is meant to look at the error code to understand it. I'd suggest you need a more compelling use case than what you've listed.

I do know that English is not my first language, but I think you have misunderstood the request. Please reconsider. The point here is that when a timeout happens, this can be a transient error - i.e the server is overloaded. Error codes and error messages are used for different things. Error messages are for humans to see, error codes are used to decide how to handle an error. That is also why the standard PHP Exception contains both fields. [1] To sum up: I do not want the messages to be removed - I want error codes added so that my code can treat different errors differently. An alternative is to have different exceptions for different errors. 1. http://no2.php.net/manual/en/language.exceptions.extending.php

This will require a non-trivial amount of work for either codes or Exception subclasses. Curl Adapter will need a mapping from builtin codes to new codes / subclasses, error codes returned by stream_socket_client() should be mapped, too. I'll leave the request as open, in hope that someone comes up with a patch for this.

@Daniel the use-case is very compelling. You don't want to show something like, "unable to connect to tcp://foobar" to a user cause they don't understand anyway. And (preg_)matching error messages to figure out what went wrong underneath is not a great way to handle errors for an application. @Alexey Do you think matching the cURL error codes is even necessary in this case. For all I care there should be more exceptions to distinguish where an exception was raised and then it could be pretty generic error codes that work across all adapters. Let me know, I'd help with this patch as I need this as well.

till, regarding this and your request #17506: Most of exceptions in Curl Adapter are raised in HTTP_Request2_Adapter_Curl::sendRequest() and are just repackaged Curl errors (curl_errno() & curl_error()). We'll still need to do a mapping of Curl error codes to differentiate between your proposed "Adapter Exceptions" (e.g. connection timeout) and "Response Exceptions" (e.g. corrupt gzip data in response).

I've added a patch which add support for error codes. The error code class is in Request2/Exception.php, too.

-- Committed implementation outlined here: http://news.php.net/php.pear.dev/54105 Please test!