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
