I agree with Alex, if there is an exception case that we expect either
the SlingServlet or other code to handle then having a typed exception
such as HttpStatusCodeException makes sense. In general I guess status
codes could be done by setting the response status and we could assume
that the main servlet would handle this by checking the response code.
I guess it depends on if you see a non-200 code as an exception or
just normal. While writing this I think I have changed my mind and am
less inclined to want a specific exception, however, I would not want
to set a request attribute since there is a mechanism using the
response code.
-paddy
On Jan 2, 2008, at 3:25 AM, Alexander Saar wrote:
Hi all,
Felix Meschberger schrieb:
Hi,
Am Montag, den 31.12.2007, 12:37 +0100 schrieb Carsten Ziegeler:
+1 for the proposal in general and I think we should drop the
HttpStatusCodeException as it seems a little bit wired to transfer a
status code by throwing an exception. And to expect that someone
will
pick it up and do the appropriate thing.
Agreed, that it is somewhat weired and strange. The idea is, that the
sling main servlet which is called to start the Sling request
processing
is catching the SlingException (and its extensions) and handle it
appropriately.
I think this is not a bad solution, as it provides a simple way to
propagate errors to the Sling main servlet which in turn is
responsible
for calling the error handler (correct me if I'm wrong, I'm new to the
project and code base). Another solution could be to have additional
request attributes that indicate errors occured previously in the
request processing. But I aggree with the statement that this will
lead
to some ugly code for checking existence of such attributes in order
to
cancel further request processing.
Regarding the HttpStatusCodeException: The question is (as mentioned
in
Alex blog post) if there is something you can do in reaction of an
exception case that reflects your error model. If so IMHO there should
be a special exception for that case. If not the
HttpStatusCodeException
is in my eyes is an appropriate solution, because it describes the
error
model of the protocol that is used between server and client so the
error handler can communicate the right error to the client.
Regards,
Alex
