Many times people complains about checked exceptions in Java, and how wonderful the world is in C# where exceptions are all unchecked.

I’m much in favor of checked exceptions: I want to know what a method can return having a knowledge as complete as possible on method behaviors.
Unchecked exceptions sounds like that any method returns java.lang.Objects or not declaring any return type at all. Like in JavaScript: you should already know that a function may eventually return something or some exception: it’s scary! I hope Java will continue having checked exceptions forever: all we need against bugs is control over the code and such kind of automatism make you loose that. I imagine how easy it is to forget to handle number parsing errors, or file not founds, etc. making software crash and programmers say “oh, I just forgot that!” or “Really users are so stupid to put ‘blah blah’ in the field named age?”

Hope everyone agrees that if your method throws unchecked exceptions you should tell users that you are doing that, right? But how? Javadocs? No programmers keep updated javadocs. This is why is much better to have self explaining code, than commented code. Checked exception are self explaining code.

But, as I like people smiling :-), I was asking myself if it is possible a workaround to make programmers that prefer unchecked exceptions be happy. Something like an option, a directive, or better an annotation interpreted by the compiler that dynamically adds throws declarations on methods in compile time. This would maintain bytecode compatibility and tools like IDE and Javadoc can continue notifying users that a method throws exceptions.

For example I think javax.rmi.RemoteException would have been unchecked (personally I don’t agree with reasons for which it isn’t)… so I’d like to be able to specify on my code that I don’t want to handle that exceptions. You simply add to your class/methods an annotation that tells the compiler to automatically add throws declaration for RemoteException and its subexceptions. You could define an interface like RemoteExceptionUnaware with such kind of annotation, and implementing that will make your code to automatically throw RemoteExceptions on all the methods needing that.

Good exception handling, now, is to have them checked for that situations that commonly can be handled and recovered. And unchecked for those unrecoverable errors that relies on system failure (hardware/network failure) or bugs (NullPointerException, ClassCastException, etc). Good code let them to reach the point in which the user is notified with a dialog that something went wrong, and you can’t do anything.


2 Responses to “The checked vs unchecked exceptions never ending wars”  

  1. 1 Ricky Clarkson

    Checked exceptions work really well for code that doesn’t change much or call out to code that can change.

    Adding a checked exception to a method can be viral – it affects the callers of that method, and even their callers. If the caller doesn’t want to handle the exception, they may catch and wrap it, but that just obscures the original point. If you and I communicate through a third party, and you know I may throw a FileNotFoundException, the third party should be capable of passing that on to you without wrapping it up.

    method1() throws FileNotFoundException {}
    method2(){method1();}
    method3(){try{method2();}catch(FileNotFoundException e){}}

    The above should work, but this is what really happens:

    method1() throws FileNotFoundException {}
    method2(){try{method1();}catch(FileNotFoundException e){throw new RuntimeException(e);}}
    method3(){try{method2();}catch(RuntimeException e){if (e.getCause() instanceof FileNotFoundException){whatever}}}

    Much more obscure. Sure, when development is ‘finished’, you can go through and add in the viral throws decorations, but when development is finished, a project is usually dead. Checked exceptions sometimes help, but they often slow you down and lead you to writing poor code like the above. I cover an alternative here: http://rickyclarkson.blogspot.com/2007/05/optional-checked-exceptions-spitting-at.html

  1. 1 Throwing undeclared checked exceptions - NewInstance


Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>


Current ye@r *


Calendar

June 2007
M T W T F S S
« May   Jul »
 123
45678910
11121314151617
18192021222324
252627282930  

Follow me

twitter flickr LinkedIn feed

Subscribe by email

Enter your email address:

Archives


Categories

Tag Cloud


Listening