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.

I think I miscommunicated: I meant "it always depends on the exception." In 
that case, I believe that we agree. :)

> > > [...] 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 :+)

I agree that checked exceptions give the compiler an opportunity to make 
people aware of exceptions that code expects to throw. Even so:

1. I don't need the compiler to do all this work for me. Often it gets in my 
way.
2. When I refactor, I have to worry about the ripple effect of all these damn 
declared exceptions. Anything that makes refactoring difficult, tedious or 
annoying is, in my opinion, a Bad Thing unless it delivers real value in the 
meantime.

I am not convinced that, overall, the value delivered by checked exceptions 
is greater than the cost.

On my current project, which of course includes database access, the entry 
point into the data access objects throws only unchecked exceptions. If our 
data access object encounters an SQLException, it wraps that in an 
ObjectStoreException. These are unexpected problems and catastrophic errors. 
When we throw an exception from within the data access object, we throw a 
subclass of ObjectStoreException, such as EntityNotFoundException, 
EntityInUseException, DuplicateEntityException. None of these exceptions are 
checked.

We don't miss a thing. If we had checked exceptions everywhere, we would run 
the risk of coupling our service code with our data access code. Bad Thing.

Does the compiler have as much information to help us uncover unhandled 
exceptions? No. 

That's why we have tests. The compiler ain't so damn smart, anyhow.

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