On 25/06/10 13:11, Michael Bedward wrote: > 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 ?
And then every library ends up inventing its own checked exception hierarchy, and you have the same problem. In practice, many developers either chain using RuntimeException or put "throws Exception" on many methods, both of which are admissions that checked exceptions are a problem. Exceptions are best used for out-of-band communication (I thought that was their purpose?), so programmers can focus on handling non-exceptional logic without being encumbered by error handling boilerplate. Checked exceptions prevent this. Java code littered with checked exception handling reminds me very much of C: int status = bar(); if (status) { return status; } Except the Java is more verbose. Good use of exceptions would we when Foo Inc provide their FooDataStoreFactory (implements DataStoreFactorySpi) and FooDataStore, have it used by GeoTools FeatureReader-using code ignorant of Foo Inc's proprietary Foo persistence layer. In the event of disaster, a FooException is thrown and propagates to the top level of their Foo Enterprise Executive Command Console, where it is caught by: } catch (FooException e) { and a friendly user notification is placed on the Swing event queue. This is only possible if FooException is a non-checked exception. -- 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