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
