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
