[email protected] ha scritto: > A big +++++1 one for this proposal, having our own > FeatureAccessException with a Constructor > FeatureAccessException(Exception ex).
We actually always had that, DataSourceException, but for some reason people decided not to use it anymore. Honestly no idea why. > 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,,,) Spring like? It may work. The thing that usually breaks in a layered library like Geotools is that people blindly catch Exception and then rewrap it in another exception even when there is no reason. At that point exception chaining plus a method that allows to get the first non DataSourceException in the chain might work better 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
