On Nov 29, 2007 9:43 AM, Rob Heittman <[EMAIL PROTECTED]> wrote:
> I'd defer to your expertise on the valid circumstances to use unchecked
> exceptions, but I can see how Sumit's approach would get part of the way
> without requiring breaking API changes. I think one could make Sumit's
> solution available "on the side" for those of us who need to start
> incorporating such things ... with a goal of moving to checked exceptions at
> some point (e.g. 1.2 or 2.0) where more API breakage is acceptable.
Let me sketch an approach that might meet both sets of concerns:
Add a subclass of Resource called, say, CheckedResource. For each high-level
"handler" method in Resource that you might have wanted to throw a checked
exception (e.g., storeRepresentation), create a corresponding method that
throws the exception (e.g., store), and implement the first method in terms
of the second.
class Resource {
public void storeRepresentation(Representation r) { ... }
...
}
class CheckedResource extends Resource {
public final void storeRepresentation(Representation r) {
try {
store(r);
} catch (StoreException e) {
setResponseFromException(getResponse(), e); // utility method
}
}
public void store(Representation r) throws StoreException { // or
whatever
throw new ServerErrorInternalStoreException();
}
...
}
Then do as Sumit does, subclassing CheckedResource instead of Resource, but
translate domain-specific exceptions (which could be unchecked if the
existing code works that way) to StoreException in your
CheckedResource.store() implementations.
--tim
