Re: distinguishing between failures and errors

You want to recover from an exception? :-)

In the projects I have worked on, 99% of exceptions are not
recoverable. More to the point it is not economically viable
to write and maintain the recovery code.

If an exception is caused by a
software error I just want the stacktrace to be logged. Forcing 
developers to write catch clauses for checked exceptions increases 
the possiblity they will lose that original stacktrace.

Have you not been in the position of debugging a stacktrace to find
that it was just a rethrow of another exception which has now been
lost?

My preference would be to use unchecked exceptions everywhere and
maybe use checked exceptions (refactor from unchecked to checked)
where I will explicitely try to do some recovery.

--
Neil Swingler

> >If they don't have to write any exception handling code they can't 
> >code errors into it. The exceptions can propogate to a single
> >point to be logged.
> >
> 
> How do you effectively handle all exceptions when they bubble up to 
a 
> single common point?
> 
> It seems to me the best you can do is log them and attempt to 
perform 
> some generic action like exiting.  Without the original context of 
the 
> exception, it may be difficult to take any intelligent corrective 
> action.  Handling an exception closer to its point of origin is 
> generally easier and less detrimental to the system.
> 
> That said, I'd agree that if all exceptions bubble to the top then 
the 
> use of unchecked exceptions eases maintenance.  Otherwise all 
methods 
> would need to declare all exceptions potentially thrown by those 
methods 
> they call, ad infinitum.  Messy, indeed.  
>