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
