I added the catch for throwable, but I'm reluctant to advocate making that the default method since imho SRAs should be failure-proof because they can be used in other contexts than the scheduled statistics retrieval. So I would like to also add the bytecode checks, similar as those that I already added for statelessness. These already caught a number of errors that would otherwise have been caught later on when related bugs appear.
On Mon, Apr 7, 2008 at 11:59 PM, Taylor Gautier <[EMAIL PROTECTED]> wrote: > > +1 > > Alex Miller wrote: > 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 > > -- 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
