Thanks Martin. That blog post nailed the answer to my question. You are the man. :]
SS On Wed, Oct 22, 2008 at 1:58 PM, Martin Davis <[EMAIL PROTECTED]> wrote: > Seen this one? > > http://radio.weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsWereAMistake.html > > Seems like a potentially nice compromise... Doesn't seem like it's > gained much traction, though. > > Sunburned Surveyor wrote: >> 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 >> >> > > -- > 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
