I haven't rigorously studied the problem yet, but my general feeling is with Tim -- checked exceptions in high level API.
In our current WebDAV and VFS stack, we have exception types that map straightforwardly to likely resource-related HTTP error status codes (NotFoundException, ConflictException...). It is much easier, more testable, more maintainable, and more readable to simply throw ConflictException wherever a condition is detected that causes 409 Conflict status, than to do a lot of error catching and status propagation locally in the code. With the extensive modeling of other HTTP and REST semantics to high level concepts in Restlet, I think it would be quite nice to supply a family of checked exception types like this deriving from, say, RestletException, and provide a means for turning these into the correct low level concepts. It's not like we can't supply our own (which we are doing right now) but it seems like a bit of valuable elegance the project could provide. - Rob ----- Original Message ----- From: "Tim Peierls" <[EMAIL PROTECTED]> To: [email protected] Sent: Wednesday, November 28, 2007 8:10:09 AM (GMT-0500) America/New_York Subject: Re: Exceptions in general On Nov 28, 2007 5:38 AM, Stephan Koops < [EMAIL PROTECTED] > wrote: I agree fully with Paul. Exceptions are the modern way to handle things, that don't are the normal way. The same thing should be possible for doPut(..), doGet(..), getRepresentation(.) and so on on subclasses of org.restlet.resource.Resource. I agree only partly. I do *not* think the lower-level Handler API should work in terms of exceptions, but I do think the higher-level Resource API should provide a standard way to map checked exceptions (perhaps only Restlet-specific) back to the lower-level handling. --tim
