It's sufficient for the safety of the system, not for the correctness of the SRAs. I already corrected a number of them that threw exceptions instead of returning empty data when no statistic data is available. This would for instance result in warning at runtime that are not needed and could confuse people. This is not a real problem, which is why I don't think I should spend more time on figuring out the correct bytecode detection. It's just that I already observed quite some SRAs that needed to be adapted ... I even wrote some of them myself initially with the wrong code! ;-)
On Fri, Apr 11, 2008 at 1:04 AM, Taylor Gautier <[EMAIL PROTECTED]> wrote: > I agree - why is the catch approach not sufficient? > > > ----- Original Message ----- > From: "Alex Miller" <[EMAIL PROTECTED]> > To: [email protected] > Sent: Thursday, April 10, 2008 3:12:50 PM (GMT-0800) America/Los_Angeles > Subject: Re: [tc-dev] Implementing SRAs > > I don't think we should do it. > > > > On Apr 10, 2008, at 5:10 PM, Geert Bevin wrote: > > Ok, I did the byte code detection, only to realize that there are of > > course ATHROW opcodes that are not explicit exception throw statements > > (for instance with synchronized statements to re-throw exceptions > > after exiting the monitor). Any tips on how to easily handle this. > > Otherwise, I'll just let this part slide, no use spending too long on > > such a thing. > > > > On Tue, Apr 8, 2008 at 8:31 AM, Geert Bevin <[EMAIL PROTECTED]> wrote: > >> 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 > >> > > > > > > > > -- > > 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 > > -- 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
