Roger that. I've done quite a bit of reading on the checked versus unchecked exceptions myself.
Thanks for the help. The Sunburned Surveyor On Wed, Oct 22, 2008 at 1:52 PM, Martin Davis <[EMAIL PROTECTED]> wrote: > Seems like a reasonable direction to me. The question of checked VS > unchecked has been debated endlessly in the Java world, with no final > resolution that I can see. Bottom line is that if you want to throw an > exception from FeatureCollection it *has* to be unchecked. The good > news is that if you *are* being a cowboy, there'll be a lot of other > buckaroos ridin' the range with ya. > > Sunburned Surveyor wrote: >> Martin, >> >> I had thought about converting the IOException to a Runtime Exception. >> The only thing I don't like about this technique is that the client >> code using the library has no control over how the Runtime Exception >> is handled. Of course, I guess you could argue that client code >> shouldn't need control over the exception handling, since Exceptions >> weren't declared as part of the interface to begin with. >> >> Perhaps I have a unique case. >> >> I can't remember, but if you can catch a RuntimeException in the >> client code, this would be a good approach. I can explain in the >> Javadoc for my libraries methods which Runtime Exceptions are thrown >> by my implementations of the interface, and why they are thrown. >> >> The Sunburned Surveyor >> >> On Wed, Oct 22, 2008 at 1:28 PM, Martin Davis <[EMAIL PROTECTED]> wrote: >> >>> You could map the checked Exception into an unchecked one (and chain the >>> original exception). This isn't going to make any difference to the >>> calling code, because it isn't expecting *any* exceptions, let alone >>> checked IOExceptions. >>> >>> There is a school of thought that contends that Java checked exceptions >>> are a failed experiment - and I think that this sort of situation is the >>> kind of thing they use to make their case. >>> >>> If you would like other precedent, Spring uses exception mapping to >>> dramatically simplify their JDBC adapter framework (and they use >>> unchecked exceptions, being heavily in the above school). >>> >>> Sunburned Surveyor wrote: >>> >>>> As part of my work on a FeatureCache for OpenJUMP I needed to write a >>>> class that implemented the FeatureCollection interface. I ran into an >>>> interesting problem while doing this. I'd like to get some advice from >>>> my more experienced programmers. >>>> >>>> Take (as an example) the add method of the FeatureCollection >>>> interface. It does not throw any Exception objects. I believe this >>>> means that implementations of this method can only throw runtime >>>> exceptions. However, my implementation of this method in the >>>> FeatureCache depends on IO operations. These IO operations throw >>>> IOExceptions. They are not runtime exceptions, so I can't rethrow them >>>> from my add method eimplementation. I don't want to just eat the >>>> IOException, or return null from the method, because then my poor >>>> OpenJUMP user won't know what is wrong. My recent reading in the book >>>> Hardcore Java also made me realize it isn't appropriate to print a >>>> message and/or stack trace to the System console, because the user may >>>> never see this. >>>> >>>> Here is what I was thinking might be a solution. I'll add a >>>> setErrorHandler method to my FeatureCache. It will accept any >>>> implementation of the ErrorHandler interface, which will define a >>>> single method. This method will look something like this: >>>> >>>> public void handleThrowable(Throwable someError) >>>> >>>> I can then access this ErrorHandler object from within the >>>> FeatureCache. This would allow me to handle an IOException from within >>>> my add method in a way that is appropriate for the handler code. When >>>> I integrate the FeatureCache into OpenJUMP I could flash a warning on >>>> the workbench GUI using this mechanism. >>>> >>>> Are there any comments on this idea? How do you guys handle similar >>>> situations, where you are writing a library that implements an >>>> interface outside the library, and you need to handle/throw undeclared >>>> exceptions? >>>> >>>> Is there an established design pattern for the solution I describe above? >>>> >>>> Thanks, >>>> >>>> The Sunburned Surveyor >>>> >>>> ------------------------------------------------------------------------- >>>> This SF.Net email is sponsored by the Moblin Your Move Developer's >>>> challenge >>>> Build the coolest Linux based applications with Moblin SDK & win great >>>> prizes >>>> Grand prize is a trip for two to an Open Source event anywhere in the world >>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>>> _______________________________________________ >>>> Jump-pilot-devel mailing list >>>> Jump-pilot-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>> >>>> >>>> >>> -- >>> Martin Davis >>> Senior Technical Architect >>> Refractions Research, Inc. >>> (250) 383-3022 >>> >>> >>> ------------------------------------------------------------------------- >>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >>> Build the coolest Linux based applications with Moblin SDK & win great >>> prizes >>> Grand prize is a trip for two to an Open Source event anywhere in the world >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>> _______________________________________________ >>> Jump-pilot-devel mailing list >>> Jump-pilot-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>> >>> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> >> > > -- > Martin Davis > Senior Technical Architect > Refractions Research, Inc. > (250) 383-3022 > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
