error type | safe to retry | examples of when error occurs |
---|---|---|
HTTPError - 4xx | No | client error, e.g., calling the api incorrectly |
HTTPError - 5xx | No | server error, e.g. bugs in server code |
Connection Error | Maybe | incorrect configurations or unavailble network |
Connection Timeout | Yes | network congestion, server too busy to responds, server being offline |
Request Timeout | Maybe | The server did not send any data in the allotted amount of time |
Requests library Exception | No | data passed in cannot be converted to json |
Other Python Exception | No | any python errors |
https://requests.readthedocs.io/en/latest/api/#requests.ReadTimeout
See also: requests doc
from requests import Timeout, HTTPError
= requests.post(url, headers=headers, data=data)
response try:
response.raise_for_status()except HTTPError, Timeout as error:
# TODO
In the event of a network problem (e.g. DNS failure, refused connection, etc), Requests will raise a ConnectionError exception. Response.raise_for_status() will raise an HTTPError if the HTTP request returned an unsuccessful status code. If a request times out, a Timeout exception is raised. If a request exceeds the configured number of maximum redirections, a TooManyRedirects exception is raised. All exceptions that Requests explicitly raises inherit from requests.exceptions.RequestException.
I argue that we should not catch connection error in user facing code as when the code deployed to prod, the code should not have connection errors that happens due to incorrect network configs?
RequestException(IOError)
---> HTTPError(RequestException)
---> ConnectionError(RequestException)
---> Timeout(RequestException)
-------> ConnectTimeout(ConnectionError, Timeout)
-------> ReadTimeout(Timeout)