One fault with checked exceptions is how inheritence was used to group what
is checked and what is unchecked. Unfortunately an analysis of the JDK etc
seems to show that exceptions use inheritence as a grouping mechanism. The
JDK often establishes a base exception for a sub system and has all related
exceptions extend that.
2 Examples:
java.io.*
IOException // generally not recoverable probably should be unchecked
FileNotFound // probably makes sense to be checked, so programs are
forced to handle and maybe ask user again.
RemoteException // probably the most famous this should be unchecked
exception
EOFException // checkness should be the same as IOException.
Perhaps just perhaps the problem is that heirarchy is both a grouping
mechanism and a way to define checkness. Therefore if a marker was applied
to an exception to denote whether it (the exception) was checked or
unchecked ignoring whether it extended exception/runtime etc perhaps things
would be better and more flexible.More hyperbole perhaps including a Checked
and Unchecked marker interfaces do the trick. The way to solve a child
implementing Unchecked if a parent was Checked would be that the compiler
would respect the most derived implements. Since Annotations were not around
its perhaps the best solution for this mess.
Parent implements Checked // compiler treats Parent as checked.
Child implemented Unchecked // compiler treats Child as unchecked
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
