exceptions and distinguishing between failures and errors

hi all...

i've been reading some of the threads regarding testing for
thrown exceptions, and read the wiki page http://c2.com/cgi/wiki?
CodingJavaUnitExceptionTests.  i'm wondering whether, in the face
of exceptions (or otherwise), anyone really distinguishes between
failures and errors.

i used to do this:

public void testForThrownException() {
  try {
    new ArrayList( 10 ).get( 11 );
    fail( "should have thrown IndexOutOfBoundsException" );
  }
  catch ( IndexOutOfBoundsException shouldBeThrown ) {
  }
  catch ( Exception ex ) {
    fail( "threw wrong exception: " + ex );
  }
}

after reading the material mentioned above, i'm leaning toward:

public void testForThrownException() throws Exception {
  try {
    new ArrayList( 10 ).get( 11 );
    fail( "should have thrown IndexOutOfBoundsException" );
  }
  catch ( IndexOutOfBoundsException shouldBeThrown ) {
  }
}

letting JUnit handle unexpected exceptions, treating them as errors
instead of failures.

now, imagine a class-under-test:

public class Foo {
  public void bar( int i ) throws FooException, BarException {
    // ...
  }
}

and a test intended to yield a FooException:

public void testForThrownFooException throws Exception {
  try {
    new Foo().bar( -1 );
  }
  catch ( FooException shouldBeThrown ) {
  }
}

since BarException is a "could happen but shouldn't", should i treat
that as a failure instead of an error by adding a catch/fail
sequence for BarException?  does it really matter, since if i'm
doing TDD i know that the last code change i made should be the
cause of the fault, so i know where to look?  when running all unit
tests, does anyone really go "uh-oh, i got three _errors_, that's way
more troublesome than three _failures_"?

my gut tells me to treat "could be thrown but shouldn't" exceptions--
that is, those advertised in the throws clauses of methods invoked
in the test, plus any runtime exceptions known to be thrown under
certain conditions (for example, IllegalArgumentException for
integer arguments out of range)--as failures, and anything else as
errors.  this goes for tests whose successful outcome doesn't involve
the throwing of a specific exception, too.  i get the feeling most
developers don't do that because they perceive the extra code
involved to be too much of a whipping to create and maintain.
or, the failure/error distinction is not important to them.  i've
been trying to distinguish between failures and errors with these
kinds of tests, and maybe i shouldn't be.

i wonder if writing exception tests in this way can sniff out "smells"
that using a particular method might be too noisy?  that is, instead
of throwing three different, possibly unrelated exceptions, maybe
have the method declare one wrapping exception be thrown?

eager to hear your thoughts.

cheers,
p

Paul Holser