On 24/06/10 21:59, Andrea Aime wrote: > looking at the feature collection and feature iterators interfaces again > I'm seeing another serious design mistake: they don't throw IOException > anywhere.
I am a card-carrying checked exception hater. They have the effect of leaking implementation details into interfaces. I lack the time today for a full-fledged rant. Here is one I prepared earlier (sent to a friend on Tuesday), about why I am looking forward to Scala: ****** I was more thinking of the way checked exception cause implementation details to leak, or exceptions to be chained. For example, if you design a DataProvider interface and know your first implementation will be an SQLDataProvider, you can either have throws SQLException on many methods, or not. If you have it, you have contaminated your interface with implementation details (what about non-SQL providers?). If you do not, you force the implementation to exception-chain, and users must go hunting through getCause() chains to find out what happened. This also prevents type-specific catch. Either way, you are stuffed. Exception handling in Java is a giant bungle. Unlike the URL debacle (failure to properly unescape paths), there is no workaround. ****** -- Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au> Software Engineering Team Leader CSIRO Earth Science and Resource Engineering Australian Resources Research Centre ------------------------------------------------------------------------------ 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 Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
