Re: distinguishing between failures and errors

--- In junit@xxxx, "J. B. Rainsberger" <jbr@xxxx> wrote:
> > > From: J. B. Rainsberger [mailto:jbr@xxxx]
> > ...
> > > > So the only thing you gain with the suggestion above is
> > > > forcing the code to be aware of the Exception possibility of
> > > > your code.
> > > 
> > > Yes: I submit that that is what tests are for. (If you're 
> > > here, then you're writing tests, after all.)
> > 
> > Isn't documentation the thing that should be used to tell the
> > writer of code that calls yours what your code is supposed to
> > do, or what the caller is supposed to do (or not do)?  (At
> > least for code meant to be re-used, such as that implementing
> > an API?)
> 
> Yes, it is. Please explain to me why unit tests are not 
> documentation. :)

i think with respect to checked exceptions your code has advertised,
unit tests are not documentation about how to react to such
exceptions.  if i've understood the preceding discussion correctly,
it is preferred in unit tests to let unexpected (read: not the
successful outcome of the test) exceptions, checked or unchecked,
propagate out of the test method so the JUnit framework can signal
the test an error, preserving the stack trace of the thrown
exception to facilitate diagnosis.  that's cool, they're tests.

but the intent of checked exceptions is to signal abnormalities from
which, in the opinion of the designer, client code should be
reasonably expected to recover.  from that perspective, the
"throws Exception" policy of the unit tests illustrates only one
possibility for handling the exceptions--that of letting your caller
deal with it.  as such, it is not the best documentation for showing
how to handle exceptions that emanate from the code-under-test.
the tests really can't make those decisions on behalf of specific
callers.  but, they do a marvelous job of describing and ensuring
behavior of the code-under-test.

great discussion!  i haven't turned my back on checked exceptions,
but i'm handling them in my tests much differently, in a way that
hopefully will make refactoring in the presence of checked exceptions
less painful.

cheers,
p

Paul Holser