So Ben.... checked exceptions in Java have there problems; as a library for the Java language it is not our problem to code around java weakness?
It looks like we have a clear group preference for: - unchecked exception now for feature iterator next() and hasNext() methods For me it is even money if we can raise that to a checked exception in a future release of GeoTools. If we are going to do so I would recommend we make use of feature reader rather which already serves this purpose. There is a real disconnect between: - working on implementations (who like feature reader and view all else as overhead) - making use of feature collection to get work done - and would like more help (and less code) Jody On 25/06/2010, at 5:40 PM, Jody Garnett wrote: > We already have DataSourceException that meets this need Christian. > > it is a checked exception however; I think what Ben is getting at is that we > should: > - make an unchecked exception > - add it to our library where needed > > Jody > > On 25/06/2010, at 3:51 PM, [email protected] wrote: > >> A big +++++1 one for this proposal, having our own >> FeatureAccessException with a Constructor >> FeatureAccessException(Exception ex). >> >> The IOException drives me crazy, because in Java 5 there is no >> constructor IOException(Exception ex), in Java 6 there is. >> >> Getting a backend exception (e. g. SQLException) is problematic. What to do ? >> a) throw new RuntimeException(sqlEx) >> b) throw new IOException (sqlEx.getMessage()) >> >> Neither of them is a lucky solution. Having our own exception makes >> the interfaces consistent, we can always save the original exception >> and we can build a nice Exception hierarchy if we need. >> (FeatureReadException,FeatureWriteException,FeatureMetaDataException,,,) >> >> IMHO, Very good idea. >> >> >> >> Quoting Michael Bedward <[email protected]>: >> >>> On 25 June 2010 14:01, Ben Caradoc-Davies wrote: >>>> [I'm going to hide under my desk until Andrea has cooled down.] >>> >>> Don't imagine you'll be safe there Ben. A few weeks ago Andrea was on >>> the verge of nuking Sydney because of something Jody said. >>> >>> This might be a dumb question (I don't know much about Exception >>> handling) but isn't the least worst approach to the problem of >>> 'leaking' implementation into interface to wrap IOException, >>> SQLException etc into some GeoTools exception class, e.g. called >>> something like FeatureAccessException, and stick that in the interface >>> signatures ? >>> >>> Michael >>> >>> ------------------------------------------------------------------------------ >>> 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 >>> >> >> >> >> ---------------------------------------------------------------- >> This message was sent using IMP, the Internet Messaging Program. >> >> >> >> ------------------------------------------------------------------------------ >> 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
