On 12/3/07, Paul J. Lucas <[EMAIL PROTECTED]> wrote:
> Funny, because java.io.FileNotFoundException is derived from
> IOException. So clearly there's precedent.
Did you notice the "io" package name? :-) The exceptions here are
about resources, not IO.
Generally I think having support for throwing exceptions for setting
result status codes and exiting at the same time is a very good thing,
I have made the mistake of forgetting to return several times, leaving
big security holes open, where the server performed the resource
deletion, but returned "Forbidden" to the client.
This would also avoid issues with multiple attempts to set the status
code, for instance a pattern would be to have a try { backendstuff() }
catch BackendFailed() { getRequest().setStatus(...) } - where the
catch-block in some cases could overwrite another status message.
On the other hand it is good to be able to have manual control over
the status code as well, as in many cases status codes are not just
"exceptions". A subclass of Resource is probably the best solution,
with exceptions subclassing a checked StatusException.
--
Stian Soiland, myGrid team
School of Computer Science
The University of Manchester
http://www.cs.man.ac.uk/~ssoiland/
