Re: distinguishing between failures and errors

> <jbr>
> > One could argue that throwing the wrong exception type is a
> > failure and not an error, but since it's impossible to distinguish
> > between simply throwing the wrong exception type and something
> > going horribly wrong, it is easiest to treat them both as errors.
> </jbr>
> 
> i think it depends on the exception.

Always.

> [...] if a method has advertised
> an exception in its throws clause, a caller can anticipate that it
> could happen, catch it, and call the outcome a failure.

I think Java's checked exceptions are evil, so I don't bother. If it ain't 
the right exception, then the production code is barfing. Barfing is an 
error -- different from, say, answering 10 instead of 8.

(For those interested in arguing about checked exceptions, first please read 
http://c2.com/cgi/wiki?CheckedExceptionsAreOfDubiousValue.)

> [...]  any other
> "unanticipated" exception would then be an error.  but in practice,
> it probably doesn't matter whether the throwing of the wrong
> "advertised" exception should signal failure or error.

Indeed. It may be impossible to tell, or at least too much work to tell, 
whether the problem was within or outside of your control. Better to hedge 
your bets unless you have a good reason to do otherwise. Cheaper, you know.

> i was trying to use the exception example as a starting point for
> discussion about whether failure/error distinctions in junit are
> meaningful to anyone.  my experience has been that they are not--
> in either case, failure or error, you're led in the direction of a
> solution.  what do you all think?

It depends on the context. When the code I'm testing does not throw its own 
exceptions, then an error is almost always either a bug in the test or a non-
recoverable problem. When the code I'm testing throws its own exceptions, 
then an error could be a bunch of different things. I suppose that, in a 
narrow context, errors are useful, but I don't really distinguish. The nice 
thing about errors, though, is that they prompt me to look beyond my code and 
my test for the problem. Maybe the disk is full. Maybe the network is down. 
Maybe there's an eclipse of the sun. An error often makes me think harder 
about where the problem might be. That's usually good.

> this, too, the failure/error distinction and whether it matters, may
> be a good FAQ item too?

Mike?

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