The biggest concern for me is that IOException is being eaten in the
client. So, for example, an illegal url or a host not found error is
being trapped, logged and then no other error is being thrown. Yuck.
There's no appropriate status code which can model a "host not found"
exception, because the status codes imply actual contact with the server.
As for checked/unchecked debate, ya it's a heated discussion. I don't
mind so much about the type of exception thrown so long as there at
least IS an exception thrown.
Jim Alateras wrote:
Anyway, if you want, you could grab the patch files from the following
bug. Alternatively, if you don't want to patch the source code, I'd
be happy to send you the jars I compiled with these changes.
http://restlet.tigris.org/issues/show_bug.cgi?id=311
Once you have this, the client will throw a (runtime) exception which
you can use like this (using your code):
try {
Client client = new Client(Protocol.HTTP);
Response response = client.post(url, objrep);
} catch (Exception e) {
// notify your user of the bad url or other problems.
}
Ultimately, what needs to happen, is that these handle methods need to
throw checked exceptions so that you as an end user _must_ catch the
exceptions. That would make for a much nicer system, since wrapping
I am just as happy with the Client setting an appropriate status code in
the returned Response instance and then i can handle it consistently
along with other status codes.
exceptions up into runtime exceptions just to get them out of a method
is bad api design.
checked vs unchecked exceptions has always been a hotly debated topic.
Personally, I subscribe to using unchecked exceptions primarily because
they don't force the client to handle the exception if they can't do
anything with it.
cheers
</jima>
