I agree. In my opinion not just sticking with FeatureReader and
introducing FeatureIterator and Iterator really messed up the api.
What do you mean by "bring back feature reader". Did it go away some how?
If we are going to "fix" the feature collection interface we could
deprecate iterator() and features() and add reader() which would return
a FeatureReader.
Before such an api change I really think it makes sense to consolidate
on feature collection implementations, making them follow the lead of
contentFeatureCollection, which already backs both features() and
iterator() by a feature reader. More of an internal thing but I think
makes the transition a bit easier.
2c.
-Justin
On 10-06-24 8:37 AM, Andrea Aime wrote:
> Jody Garnett ha scritto:
>> Around in circles we go :-P
>>
>> FeatureReader is like an iterator that throws IOExceptions ... and users
>> hated it.
>
> Who besides James hated it? ;-)
>
>> But yes I will consider it - we are trying for a much stronger sense of
>> YOUR ARE DOING IO BE CAREFUL and thrown exceptions really scream that to
>> people using a project. So although most of my feedback here will be
>> about problems; I really like the idea of an honest api that is up front
>> about exceptions.
>>
>> So is there any way we can do this and have the result be readable?
>> Right now the feature reader examples require two nested try / catch
>> block for each and every example. Here is what the user guide has for an
>> example
>>
>> SimpleFeatureReader reader = null;
>> try {
>> reader = dataStore.getFeatureReader( typeName, filter,
>> Transaction.AUTO_COMMIT );
>> while( reader.hasNext() ){
>> try {
>> SimpleFeature feature = reader.next();
>> }
>> catch( IllegalArgumentException badData ){
>> // skipping this feature since it has invalid data
>> }
>> catch( IOException unexpected ){
>> unexpected.printStackTrace();
>> break; // after an IOException the reader is "broken"
>> }
>
> Sorry, this looks retarded to me. How much code has to be so permissive
> to skip over bad data? One try/catch is enough.
>
>> }
>> }
>> catch( IOException couldNotConnect){
>> couldNotConnect.printStackTrace();
>> }
>> finally {
>> if( reader != null ) reader.close();
>> }
>>
>>
>> I have literally watched people give up and call
>> DataUtilities.collection - not because they needed to load the contents
>> into memory; just because they could not handle the exception book keeping.
>>
>> So Andrea how could we pull this off and not completely kill usability?
>>
>> Thinking...
>>
>> Given the amount of code that would break we would either need to
>> reintroduce feature reader; or update featureiterator and call the
>> result GeoTools 3.0 - as all feature reading code would be broken....
>>
>> Here is another idea - would declaring a runtime exception as part of
>> the method work? It would be honest about the possibility for error; and
>> not break existing code - and for GeoTools3 we could make it a checked
>> exception.
>
> I guess it would be somewhat better. At least the small percentage
> of users that does read the documentation would know exceptions
> can happen...
>
>> And you know I always encourage feature visitor use; making feature
>> iterator throw exceptions would help that style of programming but that
>> is a pretty weak motivation on my part.
>
> Visitors are nice for stuff that needs to aggregate the values into a
> final result, but for things like, copying over a feature collection
> content to some other format, they look pretty much counter-intuitive
> to me.
>
> Cheers
> Andrea
>
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
