I think that exactly the argument for not catching Throwable. In this case I'd catch Exception and log the message, thus allowing Error and other non-recoverable stuff to explode appropriately.
If something really bad has happened let the code/user/whatever know. Don't confuse the issue by swallowing (or attempting to swallow) the problem. Just my opinion. Tom On 3 Apr 2011 16:05, "Dan Creswell" <[email protected]> wrote: > On 3 April 2011 15:36, Patricia Shanahan <[email protected]> wrote: > >> Correct about the class name. >> >> We need to remember that Throwable includes conditions that are not >> specific to the code that throws it, but rather indicate a general problem. >> >> > Sure but if you've got one of those cases, chances are many other things > will break also because it's a general problem. > > Patricia >> >> >> >> On 4/3/2011 1:14 AM, Dan Creswell wrote: >> >>> Did you mean LookupLocatorDiscovery.Notifier? >>> >>> In regards to ignoring Throwable, it depends on the context. In this case, >>> we'd have a ServiceRegistrar that cannot respond to the request made >>> (getLocator) which is therefore either down or pretty broken. The most I'd >>> do in such a situation is dump the registrar (but you might discover it >>> again later) and issue a log message. >>> >>> Silence in this case seems like a reasonable option, guess I might want a >>> log message to help me (or a user) debug is all. >>> >>> That just leaves whether one believes in catching Throwable. I'd say it's >>> legitimate as there's a variety of problems that could result from dealing >>> in a faulty ServiceRegistrar that shouldn't ultimately disrupt the >>> discovery >>> process. >>> >>> Cheers, >>> >>> Dan. >>> >>> On 3 April 2011 04:35, Patricia Shanahan<[email protected]> wrote: >>> >>> In reviewing the code prior to applying the patch, I noticed the >>>> following in the LookupDiscoveryListener.Notifier.run() method: >>>> >>>> try { >>>> loc = regs[i].getLocator(); >>>> } catch (Throwable ex) { /* ignore */ } >>>> >>>> What do people think about ignoring Throwable? >>>> >>>> Chris, Thanks for the patch. Do you happen to have a unit or QA test for >>>> this problem? >>>> >>>> Patricia >>>> >>>> >>>> >>>> >>>> On 3/30/2011 3:05 PM, Chris Dolan (JIRA) wrote: >>>> >>>> Ill-behaved DiscoveryListener can terminate discovery notifier threads >>>>> ---------------------------------------------------------------------- >>>>> >>>>> Key: RIVER-395 >>>>> URL: https://issues.apache.org/jira/browse/RIVER-395 >>>>> Project: River >>>>> Issue Type: Bug >>>>> Components: net_jini_discovery >>>>> Affects Versions: jtsk_2.1 >>>>> Reporter: Chris Dolan >>>>> >>>>> >>>>> (bug detected in Jini 2.1, still present in 2.1.2+ trunk) >>>>> >>>>> If a net.jini.discovery.DiscoveryListener implementation throws an >>>>> unchecked exception, then the LookupLocatorDiscovery$Notifier thread >>>>> and/or >>>>> the LookupDiscovery$Notifier thread will exit prematurely. In practice, >>>>> this >>>>> can prevent the JoinManager$DiscMgrListener or >>>>> ServiceDiscoveryManager$DiscMgrListener callbacks from being invoked, >>>>> resulting in incomplete state for a registrar. >>>>> >>>>> A soon-to-be attached patch surrounds each listener invocation with a >>>>> try/catch block. >>>>> >>>>> -- >>>>> This message is automatically generated by JIRA. >>>>> For more information on JIRA, see: >>>>> http://www.atlassian.com/software/jira >>>>> >>>>> >>>>> >>>> >>> >>
