On Nov 27, 2007, at 1:38 PM, Jerome Louvel wrote:
One advantage of using the response's status is that this
information is
part of the uniform interface and can easily cross the JVM boundaries
without affecting the calling code.
I'm not quite sure what that means or why anyone would care about
crossing JVM boundaries. Can you elaborate?
If we used RestletExceptions 'in addition', we could break this
uniformity
("a handle method given two parameters carrying all the communication
info"), having two ways to bubble up the same information.
But as it is now, it's like going back to programming in C where
exiting from nested functions is tedious and error-prone. For example:
public void handle( Request request, Response response ) {
// ...
T result = otherFunc( /* ... */, response );
if ( result == null ) {
// otherFunc() must have failed
return;
}
}
If otherFunc() can fail in one of several ways, well, in order to set
the Response's status correctly, I have to pass the Response along.
Upon return, I have to check the result explicitly for failure and
return.
If RestletException existed, code such as the above is simplified,
less tedious to write, and less error-prone.
Another example is the fact that connectors use various types of
exceptions
(Simple, Jetty, etc.) so we would loose client code portability if
these
exceptions weren't converted into uniform statuses.
Yes, the *Restlet* framework code would catch the exception and
transform it into setting the status of the Response. The point of
any framework is to present an easier, more convenient API to the user
than using the raw, underlying API directly.
A funny thing is that if I were to use J2EE's HttpServlet, the doGet()
method is declared to throw ServletException.
- Paul
