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.
Actually NOT.
Integer.valueOf() which could throw java.lang.NumberFormatException, this is
part of *contract* for this method... this type of errors HAS sense... and
should be distinguished. Actually
>
> > [...] 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.
what about mixed language environment? I mean CORBA / Java or something like
this... CORBA exceptions should be proccessed in Java, catched.... so I
think checked exceptions are better, they AWARE programmers of majority of
possible exception. They are part of method contracts. I FLAME :+)
>
> (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
>
>
> To unsubscribe from this group, send an email to:
> junit-unsubscribe@xxxxxxxxxxxxxxx
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>