On Nov 29, 2007 2:31 AM, Sumit Lohia <[EMAIL PROTECTED]> wrote: > Rob Heittman <rob.heittman <at> solertium.com> writes: > > > 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. > > > > I have done something similar in my project but the exception hierarchy is > unchecked. This allows me to use the same set of exceptions in my DAO code, > and Controller code and not have to add 'throws RestletException' > everywhere. Also I can code against interfaces that know nothing about > Restlets so don't have to add 'throws RestletException' even though the > implementation might throw a derived exception like NotFoundException. I > also have a StatusService that converts these exceptions to the appropriate > HTTP error code and it works wonderfully. >
Unchecked exceptions should be reserved for when there's a problem with the program, not for exceptional application conditions that aren't actually program errors. Code that catches unchecked exceptions should almost always rethrow the exception, after cleaning up and state and perhaps logging the fact. (There are broken public APIs, including the JDK, that use the wrong kind of exception in a few places, in which case you just have to bend the rules.) A 409 Conflict, for example, is not a program error -- in the sense that it doesn't mean the application is broken -- so a ConflictException to indicate this condition would have to be a checked exception. You wouldn't have to "pollute" your code with ConflictException -- you would use exception translation in your Resource implementation to turn your application-specific (checked) exception into a ConflictException. Your Resource implementation is the bridge between the RESTful world and your domain. What attracted me to Restlet in the first place was that it offers a way for Java programmers to think and code in a natural idiom without having to be HTTP experts. (It also offers lower-level hooks, too, but I see that as a secondary benefit.) Having support for specific exceptions in the Resource methods would be just a further step in that direction. However, I don't have a concrete proposal, and I don't see an easy way to do this without breaking code for 1.1m1 users. --tim
