abdera-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neale Upstone <ne...@whirlwindmatch.com>
Subject Re: 404 should be... + Provider to throw exceptions ?
Date Thu, 01 Nov 2007 21:10:53 GMT
Mmm.. without wanting to get into a war of ideals, I'm very clear that 
2) using a search engine, is not my idea.  Code should be self 
documenting, not require integration with Google.  I want to get on with 
writing code, not hitting search engines.

Which brings me to my next suggestion:

Should Provider throw exceptions for the exception status codes (4xx, 
5xx) where there is no content?  My implmentation is tending in the 
exception direction, as I want to be able to, for example, test for 
valid media type in a utility function that throws an exception.  These 
validation utility functions could be part of the framework if this were 
the case.

e.g. the snippet

            MimeType contentType = request.getContentType();
            if (contentType != null
                    && !MimeTypeHelper.isAtom(contentType.toString()))
                return new 
EmptyResponseContext(HttpServletResponse.SC_UNSUPPORTED_MEDIA_TYPE);

could be:
    class AtomUtils...
    static public void checkContentType( request ) throws 
UnsupportedMediaTypeException;

    with Provider.java allowing a base HttpStatusException to be thrown.

This isn't something I think is in any way a "must" but it'd be 
interesting to see if people would prefer to just be able to throw an 
exception from Provider that is then translated into the status code...

Cheers,

Neale
(Today rather happy as the C and R of CRUD are now implemented)



Brian Moseley wrote:
> On Nov 1, 2007 10:49 AM, Neale Upstone <neale@whirlwindmatch.com> wrote:
>
>   
>> Disagree on the "they're well known argument from Brian, as they're
>> not.  200, 302 and 500 are all that I'd have stood a chance at in a
>> multiple choice test, as I don't usually write stuff at that low a
>> level.  And, it's an example, so should be aimed at the lowest in the
>> ecosystem, not at HTTP gurus (IMHO).
>>     
>
> it doesn't take a guru to either 1) remember commonly used status
> codes or 2) look them up in a search engine.
>
> if you're just worried about some example provider code, i won't
> grumble too hard, but i would definitely push back on a suggestion to
> do this inside the framework code.
>   

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message