Re: Patch: merge File.toURI() from Classpath

[Chris Pickett]

Bryce McKinlay wrote:
> C. Brian Jones wrote:
>
>
> > On Tue, 2004-07-06 at 12:22, David Daney wrote:
> >
> >
> >
> >
> > > If don't like the idiom new InternalError().initCause(), then add a
> > > constructor to InternalError (and perhaps Error also) so that you can
> > > pass the cause as a constructor parameter.
> > >   
> >
> > As pointed out, Classpath does not add to the published, public, API of
> > the core classes intentionally for compatibility.  I too think
> > RuntimeException would be incorrect in these situations, clearly an
> > error should be thrown instead that indicates the dire situation the
> > runtime is now in and the need to fix a potential library bug.  The use
> > of initCause() would seem appropriate if a cause exists.  
> >
> > While applications can recover from many forms (maybe all)
> > RuntimeExceptions, it is probably impossible to recover from
> > InternalErrors.
>
>
> If a library call failed because of an internal bug that results in a 
> RuntimeException being thrown, how is that different from a library call 
> that fails because of an internal bug that causes, for example, 
> NullPointerException (which extends RuntimeException) to be thrown?
>
> IMO, InternalError should be reserved for virtual machine and low-level 
> runtime errors, as suggested by the spec - not generic class library 
> bugs as is the case here. InernalError also suggests to me a more 
> serious bug than what could be occuring in these situations - ie that 
> something is seriously screwed up with the internal state of the 
> runtime, whereas a RuntimeException just means that the call failed due 
> to a bug in a peice of library code, which is what would be happening 
> here if these exceptions ever got thrown.
>
> Its something of a moot point whether an application should be able to 
> recover from these or not - they are errors that can/should never 
> happen. Even so, it is certainly possible to imagine applications where 
> continuing after a failed library call is preferrable to not being able 
> to continue at all.

Hi all,

Okay, I'll try again.  Joshua Bloch wrote a book called Effective Java 
that talks about best practices for Java programming, including those 
used by his team when implementing the Sun class libraries.  If you look 
at the extremely helpful and pertinent discussion in Chapter 8:

1) There are three kinds of exceptions, checked (subclass of Exception), 
unchecked runtime exceptions (subclass of RuntimeException), and 
unchecked errors (subclass of Error).  There is no reason to use another 
kind of exception, ever.

2) The user is expected to recover from checked exceptions, and they 
should be declared with the throws keyword, and documented with @throws. 
 The user is not expected to recover from unchecked exceptions (Error 
and RuntimeException), and methods throwing them should never declare 
that they do with the throws keyword, but should still use the @throws 
Javadoc tag.

3) RuntimeException's are what you should throw if there is a 
programming error, including if it's in the class libraries.  By strong 
convention, Error's are reserved for the JVM only (Bloch gives two 
references).  The JLS does not mandate this.

4) Always throw the most specific / descriptive exception possible, and 
try to stick to the standards for an API.

5) Some good RuntimeException examples as used by the class libraries:

IllegalArgumentException: for inappropriate parameter values
IllegalStateException: if the receiver is not in the right state
NullPointerException: non-null parameter expected
IndexOutOfBoundsException: out of bounds parameter
ConcurrentModificationException: prohibited conc. modif. detected
UnsupportedOperationException: method not supported for object

Based on the above, I would suggest IllegalStateException for the 
File.toURI() code snippet in question (just as in the API File(URI uri) 
throws IllegalArgumentException if the preconditions on the parameter do 
not hold).  I would also suggest UnsupportedOperationException rather 
than NullPointerException for stub methods (but of course as discussed 
stubs are bad in the first place).  If you read the chapter, you'll find 
it agrees strongly with Bryce's point of view.  IMO, Bloch's advice is 
very applicable since he's actually reflecting on years of experience 
implementing the exact same API.  Please try and read this book!

HTH,
Chris