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
--
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
