For the @Before methods, I agree (especially after trying to change things) because it is inherited by things that may need to throw exceptions.
For the test methods, I agree about declaring exceptions, but I really prefer to have my IDE (IntelliJ) fill in the throws list accurately. That helps me think about what might happen to a test and makes it clear to me when an API change happens. Since a missing throw is flagged instantly by the compiler, this shouldn't go undetected. This *is* a preference, but since test method are documentation, it seems good to have the documentation aspects of a test be relatively precise. On Sun, Sep 5, 2010 at 2:08 AM, Sean Owen <[email protected]> wrote: > This is really minor, don't really mind anyone doing things different > ways here, just food for thought -- > > For @Test methods, I usually declare them as "throws Exception" even > though that is almost always a bad thing. > > The badness is from an API design perspective if anything, but there > are no callers of the method here to worry about. Since a @Test method > will always wish to let any unexpected exceptions propagate up to fail > the test, it's accurate. ("throws Throwable" isn't necessary since it > would only include Error and RuntimeException which are already > unchecked exceptions.) > > The tiny upside is the @Test method depends a bit less on the code > being tested: it continues to function even if the code's declared > exceptions changes, as it should, since it doesn't care. > > > On Sat, Sep 4, 2010 at 10:03 PM, Apache Hudson Server > <[email protected]> wrote: > > See <https://hudson.apache.org/hudson/job/Mahout-Quality/243/changes> > > > > Changes: > > > > [tdunning] Removed "throws Exception". > > Put RandUtils.useTestSeed() into MahoutTestCase > > > > >
