On the flip side, I wouldn't want to end up with a switch statement with a
long list of integers.
case NOT_MODIFIED:
case OK:
is far more readable. What about this proposal?
1) Drop getStatus()
2) Define:
public class HttpConstants {
private HttpConstants() { } // Prevents instantiation
public static final int OK = 200;
public static final int NOT_FOUND = 404;
...
}
import static HttpConstants.*;
switch (clientResponse.getStatusCode())
{
case OK:
case NOT_FOUND:
}
(from Effective Java 2nd edition item 19)
Then others would be able to WebDAVConstants in the future. What do you
think? If this makes sense you might want to consider whether
Response.Status should be dropped altogether.
Gili
Sam Pullara wrote:
>
> You should definitely just return an int. There are plenty of
> services that use undefined response codes.
>
> Sam
>
> On Jan 19, 2009, at 7:18 AM, Marc Hadley wrote:
>
>> Another issue is that the HTTP 1.1 defined set of status codes is
>> extensible and I wouldn't want to litter the enum with lots of
>> unused values just in case someone comes up with some new code or
>> class of codes like WebDAV does:
>>
>> http://www.webdav.org/specs/rfc4918.html#status.code.extensions.to.http11
>>
>> Maybe we should drop the ClientResponse.getStatus method in favor of
>> the alternative that just returns an int ?
>>
>> Marc.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
>
--
View this message in context: http://n2.nabble.com/ClientResponse.getStatus%28%29-shouldn%27t-return-null-tp2179833p2195630.html
Sent from the Jersey mailing list archive at Nabble.com.