Oops, didn't see your reply here. I just replied to your other thread.
Actually, I disagree. I think the problem is that the method should
have originally been defined to through checked exceptions.
I want to be to notify the user of the exceptions inside of the client
itself. If my end user has entered a bad url, then I want to be able to
notify them about that, for example.
Setting a status code is not the way to handle this. You propose status
code 404, but that's not an appropriate response for a "host not found"
type of problem. Likewise, it's also not an appropriate status code if
the url itself was poorly formed (like, without a leading protocol scheme).
Anyway, my point is, there are many reason which a request could fail.
I want to see these in my own code so that I can do what's appropriate
with the exception.
Adam
Jim Alateras wrote:
Adam,
I came across the same problem and I believe the problem is more around
not setting the response status code on failure.
cheers
</jima>
Adam Taft wrote:
Here's a test case to look at...
public class TestClass {
public static void main(String[] args) {
try {
Request request = new Request(Method.GET,
"aaaaaaaaaaaaaaaaa");
Client client = new Client(Protocol.HTTP);
client.handle(request);
System.out.println("This code shouldn't run!");
} catch (Throwable t) {
// eat everything
}
}
}
The offending code is in HttpClientHelper#handle ...
public void handle(Request request, Response response) {
try {
HttpClientCall httpCall = getConverter().toSpecific(this,
request);
getConverter().commit(httpCall, request, response);
} catch (Exception e) {
getLogger().log(Level.WARNING,
"Error while handling an HTTP client call: ",
e.getMessage());
getLogger().log(Level.INFO,
"Error while handling an HTTP client call", e);
}
}
As soon as I get my email confirmation from tigris, I'll file a bug
report. I just wanted to mention this in case there are other areas
you know about with similar code. If the goal is to log the
exception, that's ok, but it needs to be re-thrown.
Thanks!
Adam
