sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Padraic Hannon <>
Subject Re: Rethinking Exceptions in Sling
Date Wed, 02 Jan 2008 18:15:13 GMT
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.


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

View raw message