PROPOSAL: Unchecked Exceptions as Subclasses of Checked Exceptions

[Joe Darcy]

Catching up on proposal email, I agree with the observation from Reinier 
Zwitserloot that there would be adverse behavioral compatibility 
consequences for this change since a common idiom for checking for a 
throwable that was not a checked exception would fail.

Additionally, I don't find the motivating example very compelling.

Regards,

-Joe

Alan Snyder wrote:
> Unchecked Exceptions as Subclasses of Checked Exceptions
> 
> 
> AUTHOR: Alan Snyder
> 
> OVERVIEW
> 
> FEATURE SUMMARY:
> 
> This proposal would allow the definition of an unchecked exception class
> that extends a checked exception class.
> 
> MAJOR ADVANTAGE:
> 
> Unchecked exception classes are useful when an exception must be thrown
> through an existing interface
> that does not declare any checked exceptions or an appropriate checked
> exception.
> If one can define both an unchecked exception class and a
> corresponding checked exception class such that the unchecked exception
> class extends the checked exception class,
> then the unchecked exception will be caught by a try statement that
> catches the checked exception.
> 
> MAJOR BENEFIT:
> 
> Programs do not have to explictly catch both the unchecked and checked
> exceptions. Most developers need
> only be aware of the checked exception.
> 
> MAJOR DISADVANTAGE:
> 
> A new marker interface (or equivalent) must be defined and the definition
> of unchecked exceptions changed.
> 
> ALTERNATIVES:
> 
> The alternative is to always explicitly catch both the unchecked and
> checked exceptions, which introduces
> a likely source of programming errors.
> 
> EXAMPLE:
> 
> This proposal uses a marker interface as an alternative way (besides
> subclassing RuntimeException and Error)
> of indicating that an exception class defines an unchecked exception.
> 
> The following would define a checked exception and an unchecked exception
> that extends the checked exception:
> 
> 	public class TheCheckedException extends Exception {};
> 
> 	public class TheUncheckedException extends TheCheckedException implements
> UncheckedException {};
> 
> There is no advanced usage.
> 
> DETAILS
> 
> SPECIFICATION:
> 
> The JLS would be changed to add one more way to define an unchecked
> exception.
> 
> JLS 11.2
> The unchecked exceptions classes are the class RuntimeException and its
> subclasses, and the class Error and its subclasses.
> All other exception classes are checked exception classes.
> 
> would become
> 
> The unchecked exceptions classes are the class RuntimeException and its
> subclasses, the class Error and its subclasses,
> and those subclasses of Exception that implement the UncheckedException
> interface.
> All other exception classes are checked exception classes.
> 
> JLS 11.5
> The subclasses of Exception other than RuntimeException are all checked
> exception classes.
> 
> would become
> 
> The subclasses of Exception other than RuntimeException are checked
> exception classes, unless they implement the UncheckedException interface.
> 
> The marker interface UncheckedException would have to be defined in some
> java package, with java.lang being the obvious choice.
> 
> COMPILATION:
> 
> The compiler would have to be extended to recognize the new category of
> unchecked exceptions.
> 
> I'm not aware of other changes.
> 
> COMPATIBILITY
> 
> The major compatibility issue arises from the introduction of a new name
> in the class name space. That could potentially cause a program
> to fail to compile if it imported a class with the name UncheckedException
> using a wild card import statement.
> 
> There could also be programs that examine the class hierarchy using
> reflection that would not recognize some exception classes as being
> unchecked.
> 
> 
>