As long as a malformed sra doesn't crash the server I'm flexible on the rest of the details :-)
On Apr 7, 2008, at 3:08 PM, Geert Bevin wrote: > 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 _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
