Re: distinguishing between failures and errors

Hmmm...just to jump in the middle for a
second...personally, I dislike unchecked exceptions. 
I used to like them, because, similar to your
experience, you could ignore them and not have the
ripple effect when refactoring.  However, I've seen
this as an excuse to completely ignore the exception,
in both testing and production.  Don't like that at
all.  So, I've decided to knuckle down and NOT use
unchecked exceptions whenever possible.  This *forces*
you to handle them.  

That fact that you say using them allows the compiler
to 'get in the way' sounds like a non-issue.  Is this
coupling between your two systems?  Maybe...but I
(personally) would rather have it and make damn sure
those exceptions are handled.


-Eric

--- "J. B. Rainsberger" <jbr@xxxxxxxxxxxxxxxxxxx>
wrote:
> > > > <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
> 


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com