If you were able to catch these issues and correct them then it doesn't seem like a big deal.
On Apr 10, 2008, at 6:10 PM, Geert Bevin wrote: > 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 _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
