Felix Meschberger wrote:
Hi all,
Am Montag, den 07.01.2008, 11:53 +0100 schrieb Bertrand Delacretaz:
On Jan 7, 2008 11:10 AM, Jukka Zitting <[EMAIL PROTECTED]> wrote:
On Jan 7, 2008 12:06 PM, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
... Yes, I think this is true for the 404 case, but what about other status
codes? So perhaps a ResourceNotFoundException makes more sense?
+1 It's better to do the mapping from a ResourceNotFoundException to a
HTTP 404 response in the Servlet or Filter that initiated the resource
lookup....
I tend to agree, but how would you handle the 50x (internal server
error) and 30x (redirect) cases?
Maybe using those?
a) HttpInternalServerErrorException (takes an int status parameter for
the exact value + message)
b) HttpRedirectException (takes an int status parameter for the exact
value + message)
I think exceptions also make sense in those cases - at least a), b)
is more debatable.
I agree to some extent. But thinking it further we come up with almost a
1:1 mapping of status codes to exceptions :-) This may be fine for some
commons situations like ResourceNotFoundException or RedirectException
(maybe taking a boolean to indicate temporary or permanent redirection).
But if we start defining special exceptions like an
InternalServerErrorException taking an int, I get weary.
What I think would be an idea is to have the HttpStatusCodeException a
base exception taking an in and the other exceptions extend from the
former and internally supplying the correct status code up the chain.
That is, for example in the case of the ResourceNotFoundException:
public ResourceNotFoundException extends HttpStatusCodeException {
private final String resourcePath;
public ResourceNotFoundException(String resourcePath) {
super(404, "Resource " + resourcePath + " not found";
this.resourcePath = resourcePath;
}
public String getResourcePath() {
return resourcePath;
}
}
This way, we clearly and easily throw the exception but when handling
the exception we may just catch the HttpStatusCodeException and just the
code we have.
Otherwise, our catch list would be ever growing for each new
XYZProblemException to be used to sendError.
Hmm, yes that's true. But do we really need this? I agree that an
exception for
the resource not found case is needed. But why do we need a special
exception for internal server error? Doesn't throwing any other
exception state the same? And if Sling can't handle the exception it
sends an internal server error back to the client.
I'm not sure if indicating a redirect back to the error handler makes
sense? I would rather expect that the code sends the redirct status
instead of throwing an exception.
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
