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
