Posted by timboudreau
on August 13, 2008 at 9:37 PM PDT
My friend Jon Locke, creator of Wicket, told me recently how he feels checked/unchecked exceptions should have been implemented in Java. It's an interesting idea to kick around.
I'm out in Seattle visiting my friend Jon - he has bad RSI right now, so I'm helping him out on a project. He told me an interesting idea he was kicking around when he was at Sun in 1997 or so, about how checked and unchecked exceptions should have been done. It needs thinking through, but I think it has some merit.
There are problems with some exceptions - both historical ones - things that should have been checked but aren't, and things that aren't but should have been. For example:
NumberFormatException — This is an interesting one. It's not checked. In some applications it probably shouldn't be - the application can go merrily on. In other cases you actually want to handle it
MalformedURLException — Every time a MalformedURLException is thrown, God kills a kitten. Seriously, this is an example of hyper-aggressive validation that probably made sense in HotJava, but outside writing a browser, this just clutters people's code horribly.
DataObjectNotFoundException — in nine years of writing NetBeans modules, I have never seen this thrown, but my code is littered with tests for it.
Jon's idea is simple and elegant: Allow individual exceptions, by type, to be flagged as checked or unchecked depending on a flag set on the package (if unspecified, you get the default). I.e. the compiler would understand this, and not compile something if an exception could be thrown, but if it had been flagged as unchecked, allow it to compile. Sort of like turning on and off assertions by package, but at compile time.
Anything like this would need a lot more thinking through (for example, if you call into another package with a contradictory setting to yours, what happens?).
But it's an interesting thing to think about (even if it will probably never happen for Java). What do you think?