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>
