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
