Hi Tim,
On Jun 17, 2010, at 8:50 PM, Tim McCune wrote:
> According to the Javadocs for URIParamException at
> https://jersey.dev.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/api/ParamException.URIParamException.html
> "All such exceptions of this type will contain a response with a 404
> (Not Found) status code."
> QueryParamException is one of those subclasses. Say I have a resource
> with a @QueryParam of type Integer, and the user passes a non-integer
> value in that query param (e.g. /myResource?myParam=a). Jersey will
> respond with a 404.
>
> I suppose I can see how a QueryParamException returning a 404 error
> might make sense in some scenarios, but wouldn't returning a 400 error
> make more sense in pretty much any scenario where the parameter value
> can't be coerced into the declared data type?
>
The JAX-RS EG flip flopped around this point. Since the information in
URI does not match we decided to opt for a 404 and thus it is
consistent with other parameters associated with the URI. But i can
also see the other position.
That is one the reason why we included the QueryParamException as it
allows the developer to override the response by registering an
ExceptionMapper<QueryParamException> which changes the status code to
a 400.
Paul.