-
Notifications
You must be signed in to change notification settings - Fork 321
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hide implementation details #261
Conversation
Also added a HTTP::UnexpectedError which can be used to indicate that something went wrong.
Could you give some context on why you want to wrap some of the lower level errors? I'm not necessarily against it, but having the original error class can be helpful for various error programs. Since a ECONNREFUSED can be different from the other various ECONN type errors. |
If I wanna catch all errors that Have a typo in a domain or a host that is just not reachable is pretty well inside the core domain of a HTTP lib hence I think those exceptions should be rescued and reraised to something decending from |
What error are you observing that isn't descended from In general |
HTTP.get("http://127.0.0.1:3456") Where there is nothing responding on 3456 on localhost |
So, no? |
Oh, sorry my bad for not getting my facts straight. I believed Errno::* errors decended from Exception. So what do you think about catching both of those errors and reraise them as a HTTP::ConnectionError? |
Having one class that wraps up all of the network-related errors might be nice. |
I like the idea of |
I have rebased and fixed that branch of @kwando |
Dont leak implementation details error from the connection class.
SocketError
andSystemCallError
is rescued and reraised as aHTTP::Error
instead.Maybe there should be a
HTTP::ConnectionError < HTTP::Error
class.