I'd say that I should be catching Errors as well. When reading through the javadocs (http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Error.html), it seems that re-throwing ThreadDeath and VirtualMachineError should properly let the appropriate ones propagate.
On Tue, Apr 8, 2008 at 2:45 AM, Tim Eck <[EMAIL PROTECTED]> wrote: > > > > > Yeah, it isn't cut and dry for me either. It seems that in the context of > executing an SRA, it doesn't seem like anything should be fatal though. If > an OOME happens there (but isn't propagated), it is almost certain another > critical thread will get an OOME as well. > > > > What about an AssertionError, or NoClassDefFoundError?..…they just don't > seem to be in the same category of critical things, but are still Errors. > > > > > ________________________________ > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Steven Harris > Sent: Monday, April 07, 2008 5:40 PM > > > To: [email protected] > Subject: Re: [tc-dev] Implementing SRAs > > > > > > Any Exceptions that occurs should be logged for sure. > > > I'm on the fence as to whether we want to trap Errors (OOME is an Error). > > > I'm trying to think what the impact of an OOME that was trapped and logged > would be. > > > LIkely another thread would also be unable to create memory and OOME as > well. > > > Any thoughts. > > > > > > On Apr 7, 2008, at 5:34 PM, Taylor Gautier wrote: > > > > > > > What about Errors like OOME? These should be propagated no? What do we > catch and what do we propagate? > > > Tim Eck wrote: I tend to agree with Alex here. I think others have also > mentioned (and I > second the motion) that an unhandled exception in an SRA should not be a > fatal event -- which implies catching Throwable and logging. > > Some sort of static bytecode checker doesn't hurt I guess (as long it as > doesn't produce any false positives), but it doesn't seem like a > substitute for runtime error handling. > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:tc-dev- > [EMAIL PROTECTED] On Behalf Of Alex Miller > Sent: Monday, April 07, 2008 7:42 AM > To: [email protected] > Subject: Re: [tc-dev] Implementing SRAs > > If this is a requirement that must be met by all SRA implementations > for safety, I would catch Throwable in the framework on > retrieveStatisticData. Seems like we shouldn't rely on javadoc for > the safety of the system. Instead of preventing SRA implementers from > throwing exceptions, why not just catch them explicitly and handle > them in a standard way? That seems more straightforward than > examining their bytecode and telling them they're naughty. > > On Apr 7, 2008, at 9:22 AM, Geert Bevin wrote: > > > Hi everyone, > > a small note to highlight that when an SRA is implemented, you should > *imperatively* read the javadocs of the > com.tc.statistics.StatisticRetrievalAction interface. For example, the > retrieveStatisticData method stipulates that no exceptions > whatshowever should bubble up. The main reason for this is that SRA > executions should never ever compromise the state nor the runtime > behavior of the system they are running in. A exception that bubbles > up can cause the client to exit for instance. > > I'm considering adding statements that catch all throwables whenever > retrieveStatisticData is executed, but I'm reluctant because that > could lead to sloppy implementations when people just go ahead and > throw runtime exceptions. Now that I think of it, I might actually > analyze the bytecode of the retrieveStatisticData methods of the > registered SRAs in the SRACorrectnessTest tests and fail if there are > exception throws. Any thoughts on this? > > Thanks, > > Geert > > PS.: now that I think more about it, I'll probably do both ... ensure > that the system stays up and prevent the developers from writing bad > code ;-) > > -- > Geert Bevin > Terracotta - http://www.terracotta.org > Uwyn "Use what you need" - http://uwyn.com > RIFE Java application framework - http://rifers.org > Music and words - http://gbevin.com > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev > > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev > > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev > > > > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev > > > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev > > -- Geert Bevin Terracotta - http://www.terracotta.org Uwyn "Use what you need" - http://uwyn.com RIFE Java application framework - http://rifers.org Music and words - http://gbevin.com _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
