Trouble is the Error could have come from a remote JVM, do you want that blowing up the local one?
On 3 April 2011 19:08, Tom Hobbs <[email protected]> wrote: > 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 > >>>>> > >>>>> > >>>>> > >>>> > >>> > >> >
