Once upon a time Java created an experiment called checked-exceptions, you know, you have to declare exceptions or catch them. Since that time, no other language (I know of) has decided to copy this idea, but somehow the Java developers are in love with checked exceptions. Here, I am going to "try" to convince you that checked-exceptions, even though look like a good idea at first glance, are actually not a good idea at all:Empirical Evidence Lost in Noise Unreachable Code bytesToString(byte[] bytes) { Closures Don't Like You Lost Fidelity You can't do Anything Anyway How I deal with the code Always catch all checked exceptions at source and rethrow them as LogRuntimeException.LogRuntimeException is my runtime un-checked exception which says I don't care just log it. Here I have lost Exception fidelity. All of my methods do not declare any exceptions As I discover that I need to deal with a specific exception I go back to the source where LogRuntimeException was thrown and I change it to <Specific>RuntimeException (This is rarer than you think)I am restoring the exception fidelity only where needed. Net effect is that when you come across a try-catch clause you better pay attention as interesting things are happening there.Very few try-catch calluses, code is much easier to read. Very close to 100% test coverage as there is no dead code in my catch blocks.
Your strategy is similar to Ant, with a BuildException something you can throw anywhere. But remote calls doesn't like the undeclared stuff so well, another reason why not to like RMI or SOAP
ReplyDeleteI think checked exceptions are a good idea, but are so easily abused that they need changing. The way C# deals with exceptions is equally as terrible, just by "pretending they're not there". It's like writing "throws Exception" on everything.
ReplyDeleteThe evidence is in Microsoft's own frameworks. Ever used Sharepoint? You don't get exception messages when things go wrong, just "object not set to an instance of an object". Silverlight? No exceptions, we'll just give you a blank screen, 'cos we didn't inform you that what you were doing could throw exceptions.
So I think unchecked exceptions are just as bad as checked exceptions. What we need is something else...although I'm not sure what that is yet...
I think a good trade-off for checked exceptions would be if there was an annotation equivalent. We could easily indicate to the tools the possible code's behavior and don't force anybody to rethrow the exception or otherwise clutter the code.
ReplyDelete