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
