Craig, Thanks - I agree that it is never good to break people...but currently we are limiting the use of a very powerful testing framework. Exceptions are meant to be thrown with JUnit, they will come across as errors in JUnit and be registered as a failure. By not letting people throw exceptions from these methods we will force them to either catch and manually fail the test, catch and throw a runtime, or put the logic elsewhere. Personally, I don't like putting try catch logic in my tests for unexpected exceptions...I rely on the JUnit test to show a failure in these cases.
As a developer I believe it is better to break a few people early in the lifecycle...the longer you wait the more the more people it will impact. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig McClanahan Sent: Thursday, August 10, 2006 1:10 PM To: [email protected] Subject: Re: FW: Shale Test - Exceptions On 8/10/06, Butash, Bob <[EMAIL PROTECTED]> wrote: > > Craig, > > Correct the AbstractJsfTestCase .java has never thrown Exception from > the setup and tearDown methods. But JUnit's TestCase, which is the > super class does throw Exceptions from these methods. The > AbstractJsfTestCase is altering the original method signature and > restricting the ability to throw exceptions. I took the liberty of opening an RFE for this issue[1]. I agree with the principle ... but breaking existing uses of this base class seems a bit unfriendly. Craig [1] https://issues.apache.org/struts/browse/SHALE-249
