Checked exceptions (Re: 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. <snip />

Indeed, they are not, nor can they be.

> 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. <snip />

This, combined with the preceding, makes me ask this question:

    If the intent of checked exceptions is to signal a situation
    from which the caller is expected to decide how to recover, then
    how is it possible for the code under test to suggest how to
    recover from such exceptions?

Presumably, if the code under test knows how to recover from the exception, 
it would handle the exception itself; however, it throws the exception, 
saying, "I don't know what to do here. You figure it out." In the latter 
case, there is nothing to document except "You have to catch these 
exceptions." I agree that this information is not properly conveyed by unit 
tests; however, it is entirely conveyed by the signature of the method. No 
additional documentation is likely required.

I'm not saying the additional documentation is *bad*, necessarily; but it 
ought to be questioned. It is usually not required.

> 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.

That's the goal: to use them better. You help me to do it; I help you to do 
it. We all win.

--
J. B. Rainsberger,
President, Diaspar Software Services
Let's write software that people understand.
http://www.diasparsoftware.com/
telephone: +1 416 791-8603