Consistent exception types and error reporting #792
Comments
|
Yes, I think the key is to have an easy way to distinguish between retryable (no request was sent) and non-retryable errors. So we had to look at the embedded error codes (e.g. Maybe there are not too many of those, our list is big primarily because we are able to retry for some other error conditions as well, having knowledge of whether the API called was idempotent. But yes, having something in HTTP.jl to tell what can be retried safely in all cases and what can not will be a big plus. |
quinnj
added a commit
that referenced
this issue
Jun 14, 2022
Closed #792. In particular, calling `HTTP.request` will result in one of four possible exceptions: * `HTTP.ConnectError`: something went wrong trying to make a connection to the remote * `HTTP.RequestError`: something went wrong sending/receiving request/response * `HTTP.StatusError`: a 4XX or 5XX response status code was received and status_exception=true * `HTTP.TimeoutError`: the request timed out waiting for a response (if `readtimeout` != 0) Looking over open issues and how downstream repos use HTTP.jl, I found it would be helpful if HTTP.jl indeed had more consistent exception types in place for 1.0 that packages could rely on.
|
Ok, PR up to make HTTP.jl exceptions more consistent/predictable: #846 |
quinnj
added a commit
that referenced
this issue
Jun 14, 2022
* Make HTTP.jl exception types more consistent Closed #792. In particular, calling `HTTP.request` will result in one of four possible exceptions: * `HTTP.ConnectError`: something went wrong trying to make a connection to the remote * `HTTP.RequestError`: something went wrong sending/receiving request/response * `HTTP.StatusError`: a 4XX or 5XX response status code was received and status_exception=true * `HTTP.TimeoutError`: the request timed out waiting for a response (if `readtimeout` != 0) Looking over open issues and how downstream repos use HTTP.jl, I found it would be helpful if HTTP.jl indeed had more consistent exception types in place for 1.0 that packages could rely on. * rename file
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It would be good to have better consistency in error reporting and particularly exception types/codes. Currently HTTP.jl throws various sorts of exceptions and some can get thrown to the user from internal layers like Sockets (DNS lookup) and MBedTLS (unexpected stream errors).
This makes writing reliable applications on top of HTTP.jl quite hard, as you never know quite which error type to expect or what it means. In particular, which errors should be retried and which are likely permanent? Related code:
Overall I think HTTP.jl should probably wrap all errors it receives from internal layers into a minimal number of official HTTP.jl error types and document the circumstances in which they can be thrown. (For example, Downloads.jl has just one error type with many codes. I'm not sure what the best design is here.)
The text was updated successfully, but these errors were encountered: