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 Fri, 02 Nov 2007 12:50:55 GMT

> On Nov 1, 2007 2:10 PM, Neale Upstone <neale@whirlwindmatch.com> wrote:
>> 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.
> listen, i don't mean to be rude, but i don't think it's asking much to
> know what the http status code means if you're going to work with an
> http-based protocol. the provider abstraction is not meant to make
> your applications unaware of their existence in an http environment.
That may be true, if I weren't also working on fuzzy matching 
algorithms, Spring Framework, etc, etc.

It's a moot point anyway, as it's just example code we're talking 
about.  No one is saying that you can't do what you want in your own 
code.  It really is a case of whether you are committed to open source 
code that is easily peer reviewed when someone's stepping through 
wondering why things are behaving oddly.

As for the "extra" typing... in Eclipse, it's HSR Ctrl-Space, .SC and 
then take your pick, complete with Javadoc :)
It's just the way many developers work nowadays... not working from 
memory, but from instant online documentation.  Back before these wizzy 
IDEs, I'd have agreed.

> with that said...
>>     class AtomUtils...
>>     static public void checkContentType( request ) throws
>> UnsupportedMediaTypeException;
>>     with Provider.java allowing a base HttpStatusException to be thrown.
> i've actually used this pattern with great success in a slightly
> different area. my server supports both atom and webdav, and i've
> created a dav protocol handler using the same basic request
> handler/provider design as abdera's. the main difference is that dav
> providers throw specifically typed exceptions that are caught and
> output by the request handler. it is the job of the exception class to
> provide a) a status code and b) an xml document describing the error.
> one of the items on my task list, forever bumped to the bottom, is
> incorporating this exception handling mechanism into the abdera server
> framework.
That'd certainly be great, and make implementing Providers even easier 
than it is now.

> in general i agree that code should be expressive. i only take issue
> with the suggestion of replacing well-known status codes with
> constants that take 10 times as many characters to type, and to read,
> when there's intellectual value in knowing the codes themselves.

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