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
