php-http / httplug

HTTPlug, the HTTP client abstraction for PHP

Home Page:http://httplug.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Timeout

teplyakoff opened this issue · comments

How can I handle Timeouts independently of client realization?

guzzle-6-adapter:
Http\Client\Exception\NetworkException: cURL error 28: (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)
or
Http\Client\Exception\NetworkException: cURL error 28: Operation timed out after 5000 milliseconds with 0 bytes received

curl-client:
Http\Client\Exception\NetworkException: Timeout was reached

socket-client:
Http\Client\Exception\NetworkException: Connection timed out

buzz-client:
Http\Client\Exception\TransferException: Timeout was reached

You and I creating some client realization can choose any type of Exception and message.

Ideally NetworkException should be thrown, in case of the Buzz client I would consider it a non-BC bug. As for excaption type: maybe we should create a domain exception for this case? /cc @php-http/httplug

Anyway, I don't think there is a real life scenario for distinguishing between different types of network errors.

I want to track how many requests I send and how many timeouts are reached
Should I catch NetworkException and parse exception message to find 'timeout' or 'curl error 28'?

if you log all your exceptions, can't you group them by curl error codes and build statistics on those groups? then you see which problem happens how often. imho this does not need to be generic, as its about monitoring your app which is using a concrete client implementation.

httplug exceptions need to distinguish between things that the client needs to act on programatically.

AFAIK even timeout error does not mean there is a real timeout in 100% of the cases, as your connection may broke but PHP will still treat this as a timeout (maybe i'm wrong).

Can we close this?

Yeah, I think we can close this. There is an open issue on the Buzz adapter.