Open jlmuir opened 8 years ago
We should probably wrap it inside Flow to offer the same error behavior on iOS/Android and to also simplify dev work.
Might have to change the API a little bit. Or add an "error" field on the response object.
session.get("/ip") do |response|
if response.status == 200
UI.alert({title: 'Client IP Address', message: response.body['origin'], default: 'OK'}) {}
else
p response.error # Net::Error
end
end
Net::Error would have some basic fields (message, code?) and also the classic Flow proxy
field which would give access to the underlying platform error object.
@amirrajan what do you think?
@jjaffeux Seems pretty good to me. I'm really for unifying the way it works across platform rather than having to rescue a specific exception. A response.error
object would be enough for my usage.
@amirrajan @Bounga
A wild API idea:
# Multiple goals are achieved with this API
# - no nil check on response.error
# - no integer check on various status
# - more readable
# - clear separation between completion/failure of request
# and http success/error/... codes
session.get("/ip") do |response|
response.complete {
on(:info) { }
on(:success) {
UI.alert({title: 'Client IP Address', message: response.body['origin'], default: 'OK'}) {}
}
on(:redirect) { }
on(:client_error) { }
on(:server_error) { }
on(:client_error, :server_error) { }
on(300, 301, 304, 422, 500..503) { |error| some_logic(response.status) }
}
response.failure { |error| present_error_screen(error) }
end
Interesting idea. Thanks for working on this. Been doing much Javascript lately? :stuck_out_tongue:
Some thoughts:
response.failure
also cover 4xx and :client_error or just pure connectivity errors?@jjaffeux I like these ideas. I think maybe it could be flattened a little bit to avoid too many nested blocks. What do you think about this:
request = session.get("/ip")
request.on(:success) do |response|
UI.alert(title: 'Client IP Address', message: response.body['origin'], default: 'OK')
end
# I would assume that 3xx redirects would be performed automatically by default
request.on(:error) do |response|
case response.status_code
when 400..499
UI.alert(title: 'You messed up', message: response.body['errors'], default: 'OK')
when 500..599
UI.alert(title: 'Server Error', message: response.message, default: 'OK')
end
end
# or even simpler, as you mentioned:
request.on(:client_error) do |response|
UI.alert(title: 'You messed up', message: response.body['errors'], default: 'OK')
end
...or maybe this:
session.get("/ip") do |response|
response.on(:success) do
UI.alert(title: 'Client IP Address', message: response.body['origin'], default: 'OK')
end
response.on(:client_error) do
UI.alert(title: 'You messed up', message: response.body['errors'], default: 'OK')
end
# ...
end
...or maybe this:
session.get("/ip") do |response|
if response.success?
UI.alert(title: 'Client IP Address', message: response.body['origin'], default: 'OK')
elsif response.client_error?
UI.alert(title: 'You messed up', message: response.body['errors'], default: 'OK')
elsif response.server_error?
UI.alert(title: 'Server Error', message: response.message, default: 'OK')
end
end
@andrewhavens @hboon thx for the great insights, I've been toying with multiple apis the last days, nothing finished yet.
My main concerns are:
My personal reference is http://docs.python-requests.org/en/master/
I have an iOS app where the user supplies a base URL for a service, and the app makes HTTP requests against the service via Flow's
Net
module. The app will crash with aRuntimeError
while making an HTTP request if a problem occurs such as: the URL contains a host part that does not resolve in DNS, a connection to the service could not be established, etc. There seems to be no way to handle exceptions related to making the HTTP request.To reproduce:
Add the following (which contains a bad host part (i.e., a trailing
x
) in thebase_url_supplied_by_user
value) toAppDelegate#application:didFinishLaunchingWithOptions:
after@window.makeKeyAndVisible
:Then run it in a simulator:
This results in a crash with the following message:
Similarly, if no HTTP server is running on port 80 on the loopback device, changing the value of
base_url_supplied_by_user
to'http://127.0.0.1'
results in a crash with the following message: