That's rather oversimplifying matters. In particular, its just not true that
the pro checked exception camp can "write exactly the same code as now".
Writing code is an act. It involves more than hitting keys on a keyboard.
You look at a screen. Your editor tells you things. One of the things
that'll be changing is that your editor is no longer telling you that you
forgot to handle a checked exception.
I _DONT_ like checked exceptions all that much and I'll say right now that
removing them wholesale from java is a very painful idea. Whenever I write
code calling a method that reports expectable errors via checked exceptions
(FileNotFoundException for example), even if I remember the exact type of
that exception, I'll just write the line, wait for the error, and then
quickfix the error. I'm so used to this that my muscle memory is going to
have a lot of trouble adjusting to a world where this does not happen.
In the spirit of your argument, what can we pragmatically do for java given
the need to maintain backwards compatibility? The pipe dreams painted by
Kevin Wright and other functional fans of basically rewriting APIs to return
Eithers or CPS or other paradigms is obviously not a solution (to be fair to
them, that wasn't the discussion then).
I only see 2 workable options:
(A) Define that henceforth all exceptions are to be unchecked. This is
backwards compatible, in that all code that compiles today will compile
tomorrow and do the same thing. But, as I said above, this isn't all that
compatible with muscle memory and existing library designs.
(B) Give an option to officially 'ignore' an exception, meaning you can
throw / fail to handle a checked exception without declaring that you
'throw' it. This change would go along with the ability to catch a checked
exception even if no statement in the try block appears to throw it,
generating just a (suppressable) warning, instead of java6's current
behaviour where this is an error. For example:
public String readWordList() ignores IOException {
InputStream in = MyClass.class.getResourceAsStream("wordlist.txt");
......
}
The above example is rather poignant, too, as such code will throw an
IOException exactly as likely as a ClassNotFoundError, which is so far to
the 'unexpectable and unhandleable' side of the chart that it's not even a
RuntimeException, it's an Error.
Is there a serious problem here for those who consider the checked exception
experiment a total failure? I already know from espousing this view
elsewhere that checked exception purists don't feel this is pure enough.
Pointing out that you can effectively ignore exceptions already with some
fancy generics abuse, or interop with _ANY_ non-java language on the JVM,
does not appear to help. But what about those who don't want checked
exceptions at all? Would this be a fair compromise?
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
