• P (unregistered)

    REST in frist?

  • Mischa (unregistered)

    At least I encountered "REST" interfaces that returned a variant of 200 for what is an error so it might just be a fix for that.

  • akozakie (unregistered)

    @Remy, you're reading too fast. It's using @NonNull, not @NotNull...

  • RLB (unregistered)

    And then there's @SuppressWarning("null"), which might or might not suppress or augment the @NonNull directive. Who knows? Not Oliver's cow-orker, apparently.

  • (nodebb)

    Another thing to note is that the @NotNull error was suppressed in the first line of the code sample, so even if the library loaded properly, it would not give an error. Hmm, I think I can see the logic here. "Let's see. Ah, this does almost what I want. I will copy this chunk of code and tweak it to work." ... "There. Now to compile." ... "What? NULL assignment error? Hmm, look up in the docs about how to keep a NULL assignment error from showing. Ok, I can fix that by putting this @SuppressWarning statement up here." ... "There now it compiles without errors."

  • David T (unregistered)

    And you might be thinking to yourself, “Wait, shouldn’t any reasonable HTTP client raise an exception if the status code isn’t a success?” You’d be right, and that is what this client does. So if the status isn’t a success code, the error throw statement will never execute.

    What?

  • Brad (unregistered)

    A very clever way of ensuring it's not not @NonNull

  • Conradus (unregistered) in reply to David T

    HttpClient.execute(request) will itself raise an exception if the http request errors out. Therefore it will never return in such a case but instead go to its own error handling code. So if there is really an error returned from the server, the throw shown in article's code will not execute, because none of the code following HttpClient.execute(request) ever runs.

  • ooOOooGa (unregistered)

    the error throw statement will never execute, meaning we only error if there isn't one.

    Hold on. That's not quite right.

    try { response = httpClient.execute(request); } catch {}

    if (response.getStatus() != 200) { ... }

    There. Now we only error if there isn't one.

  • Rob (unregistered) in reply to Conradus

    That HttpClient looks an awful lot like Apache's HttpClient which does not throw an exception on a 4xx or 5xx response. It can thrown a ClientProtocolException but that's if there's something really wrong in the HTTP communication, not if a 4xx or 5xx response is returned.

    Source: https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/client/HttpClient.html#execute(org.apache.http.client.methods.HttpUriRequest)

  • Rob (unregistered) in reply to Rob

    A closer looks shows it's not Apache's HttpClient - the HttpResponse does not have a getStatus() method; instead it needs to be getStatusLine().getStatusCode().

  • (nodebb)

    Wait, shouldn’t any reasonable HTTP client raise an exception if the status code isn’t a success?

    Wellllll in .NET, WebClient did, but the newer HttpClient does not (unless you call EnsureSucessStatusCode), so… ¯\_(ツ)_/¯

  • jeepwran (unregistered) in reply to Mischa

    That's kind of what I was thinking. I've seen plenty of WTF on the server side that would completely justify almost any client WTF.

  • Vicki (unregistered)

    The parentheses aren't balanced; it looks like the closer for RuntimeException is absent. XKCD 859

  • Just for Laughes (unregistered)

    Facebook's Aroma searches for snippets of code you are likely to type.

    I bet I can run that through something that writes all the code for you.

    Programmers just sit in recliner, watch TV, and change the channel if they don't like it.

    If they don't get paid, bad things happen.

    How's that?

    Is the WTF dead yet?

  • (nodebb)

    And you might be thinking to yourself, “Wait, shouldn’t any reasonable HTTP client raise an exception if the status code isn’t a success?” You’d be right

    No, I'd be wrong. It is not reasonable behaviour. Exceptional cases for an HTTP operation are things like a TCP RST in the middle of the transfer, a failure to connect, a response from the server that contains just "GLOB" (and nothing else, no server headers, no CRLFs, nothing, just those four characters) and stuff like that.

    Getting back a 4xx or a 5xx means that the HTTP operation completed successfully (from a protocol point of view), so the HTTP Client object did its job, and should return the information that was obtained.

  • Simon (unregistered) in reply to Steve_The_Cynic

    Agreed... throwing exceptions might be reasonable for a higher-level API, but not for one built around request/response primitives. At that level, a 4xx or 5xx response is no more an error than 200 is... even automatically following redirects would not necessarily be desirable...

  • Ricardo Rossello (unregistered)

    Caiganle encima a esa puta!

  • Jono (unregistered) in reply to ooOOooGa

    Not exactly. Yes, not all ok responses will trigger an exception. As you noticed, a 200 response is ok. But a 201 will trigger that exception. Which is an ok response. An error response, however, will never trigger that exception, b/c there would already be an exception in the http client (which I think is a terrible idea, but whatever). What comes out is, like said in the article, that only an ok response (From 201 and up) will trigger that error; an actual http error never would.

  • Ricardo Rossello (unregistered)

    Caiganle encima a esa puta!

  • (nodebb) in reply to P

    fREST

    FTFY

  • dpm (unregistered)

    since the comparison test implies that getStatus() returns an int, the code

    String.format( "Http request failed with status %s", response.getStatus() );

    will itself throw an exception since it is expecting a char* but gets an int (unless whatever language this is works more miraculously than I think).

  • (nodebb)

    No. Reasonable HTTP client wouldn't throw an exception if it got a valid HTTP response, no matter the status code. It would throw an exception if it failed to connect, timed out or something like that. But then expecting any HTTP client to be reasonable is not reasonable.

Leave a comment on “Null Error Handling”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article