Re: Rethinking Exceptions in Sling

[Alexander Saar <al...@googlemail.com>]

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

Re: Rethinking Exceptions in Sling

[Padraic Hannon <pi...@wasabicowboy.com>]

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