On 28-Nov-07, at 12:20 PM, Rob Heittman wrote:
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.
We do this in our application too.
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.
I am not sure Restlet needs to do it... wrapping the current API may
be too application specific?
--Toby
- 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
