Around in circles we go :-P
FeatureReader is like an iterator that throws IOExceptions ... and users 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"
}
}
}
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.
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.
Jody
On 24/06/2010, at 11:59 PM, Andrea Aime wrote:
> Hi,
> looking at the feature collection and feature iterators interfaces again
> I'm seeing another serious design mistake: they don't throw IOException
> anywhere.
>
> This is not sane imho, grabbing a collection, getting the feature
> iterator, iterating over the features are all occasions in which
> you hit file, network or database access: they should throw
> checked exceptions imho.
>
> What do you think? We're still in time to fix this blunder before
> 2.7.0 is released.
>
> Cheers
> Andrea
>
> --
> Andrea Aime
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>
> ------------------------------------------------------------------------------
> 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
------------------------------------------------------------------------------
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
