preventing http.get from returning nil
#1
Posted 12 November 2012 - 07:03 AM
If http.get() calls a website which returns for example a 404 Not Found. the method will return nil.
My suggestion is to change that. you will the be able to find out why the http request failed. this would make error handling and outputting a lot easier. to prevent the change from breaking existing programs you could also add a second parameter to http.get which is a boolean whether to return nil(set it to false or nil) or a handle(set it to true) if an error occured
greetz, Stiepen/Kilobyte
#2
Posted 12 November 2012 - 07:16 AM
#3
Posted 12 November 2012 - 08:48 AM
#4
Posted 12 November 2012 - 08:49 AM
AfterLifeLochie, on 12 November 2012 - 08:48 AM, said:
If we return the object anyway, you can just call getStatusCode on the http object.
#5
#6
Posted 12 November 2012 - 10:37 AM
#7
Posted 12 November 2012 - 12:29 PM
AfterLifeLochie, on 12 November 2012 - 09:11 AM, said:
even 404 returns typically have body.
#8
Posted 12 November 2012 - 05:36 PM
ElvishJerricco, on 12 November 2012 - 12:29 PM, said:
Yes, but the present behaviour is nil on failure, in contrast with a HTTP code response.
If we actually get an object back then the response would contain a document anyway, but, if people just look for *a* response, they might take an "error" as a valid reply (and so, checking should occur on the HTTP reply).
#9
Posted 12 November 2012 - 05:59 PM
AfterLifeLochie, on 12 November 2012 - 05:36 PM, said:
ElvishJerricco, on 12 November 2012 - 12:29 PM, said:
Yes, but the present behaviour is nil on failure, in contrast with a HTTP code response.
If we actually get an object back then the response would contain a document anyway, but, if people just look for *a* response, they might take an "error" as a valid reply (and so, checking should occur on the HTTP reply).
I think that if that's the case, they'll likely be using the http.get or http.post functions (as they'd rather do that than roll their own with http.request) so maybe have those two functions do what you're talking about, but have http.request return something we can deal with? I dunno I'm looking for the best of both worlds because I *want* my 404 failure bodies.
#10
Posted 12 November 2012 - 06:31 PM
ElvishJerricco, on 12 November 2012 - 05:59 PM, said:
AfterLifeLochie, on 12 November 2012 - 05:36 PM, said:
ElvishJerricco, on 12 November 2012 - 12:29 PM, said:
Yes, but the present behaviour is nil on failure, in contrast with a HTTP code response.
If we actually get an object back then the response would contain a document anyway, but, if people just look for *a* response, they might take an "error" as a valid reply (and so, checking should occur on the HTTP reply).
I think that if that's the case, they'll likely be using the http.get or http.post functions (as they'd rather do that than roll their own with http.request) so maybe have those two functions do what you're talking about, but have http.request return something we can deal with? I dunno I'm looking for the best of both worlds because I *want* my 404 failure bodies.
http.status; http.getResponse(); http.getErrorResponse();
Everyone's happy. />
#11
Posted 12 November 2012 - 06:43 PM
AfterLifeLochie, on 12 November 2012 - 06:31 PM, said:
ElvishJerricco, on 12 November 2012 - 05:59 PM, said:
AfterLifeLochie, on 12 November 2012 - 05:36 PM, said:
ElvishJerricco, on 12 November 2012 - 12:29 PM, said:
Yes, but the present behaviour is nil on failure, in contrast with a HTTP code response.
If we actually get an object back then the response would contain a document anyway, but, if people just look for *a* response, they might take an "error" as a valid reply (and so, checking should occur on the HTTP reply).
I think that if that's the case, they'll likely be using the http.get or http.post functions (as they'd rather do that than roll their own with http.request) so maybe have those two functions do what you're talking about, but have http.request return something we can deal with? I dunno I'm looking for the best of both worlds because I *want* my 404 failure bodies.
http.status; http.getResponse(); http.getErrorResponse();
Everyone's happy. />
Meh. I just think that's a little weak. I'd really much rather not have a layer of abstraction that doesn't make much sense on the lower levels.
#12
Posted 13 November 2012 - 03:31 AM
While experimenting and researching I found the following:
Quote
That means if the server returns a response code >= 400 then getInputStream() will throw an IOException.
Possible solution (in HTTPRequest):
Before:
InputStream is = connection.getInputStream();
After:
InputStream is; if (connection.getResponseCode() < 400) { is = connection.getInputStream(); } else { is = connection.getErrorStream(); }
Edit:
Even if this fix were to be implemented, having only http_failure as a fail event would still be too abiguous, as others have mentioned.
Suggestion:
Let it return the same values as http_success does, so that the returned response code would either be whatever the connection returned, or 0 if there was no successful connection.
This way one can distinguish the different states better:
- http_success, response < 400 --> Connection successful
- http_failure, response >= 400 --> Connection successful, but returned an error
- http_failure, response == 0 --> Connection not successful
#13
Posted 13 November 2012 - 07:10 AM
#14
Posted 30 June 2015 - 02:25 PM
Cloudy, on 13 November 2012 - 07:10 AM, said:
I just want to ask because this is annoying me a lot, but why does it still return nil when the request is like anything except status 200???
I want to know what I did wrong, but no I have nothing to bugtest with!?!
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users