J and I and Me
2013-05-28
  Why Java's Checked Exceptions Are an Issue
Exceptions were originally introduced to make programs safer. Back in the days languages like C used return codes to signal whether the call was actually successful. The return codes could easily be ignored. So you end up with a program that just continues executing - even though an error occured. Exceptions are meant to solve this. To signal an error an exception is thrown. This exception has to be handled if the error should be resolved. Handling the exception is separated from the rest of the control flow e.g. in a try-block. So handling an error is separated from the rest of the program. Java introduced three types of exceptions: Originally I thought an exception is an extension of the return type of a method. Instead of a value of the "normal" return type it throws or "returns" an exception. So if the program should be sound concerning types every type of exception needs to be handled - just as you would handle a normal return value. Obviously it makes sense to use the type checker to ensure this happens. So checked exceptions make a lot of sense. Checked exceptions are also used throughout the Java APIs. The developers of these APIs obviously know what they are doing - so again checked exceptions again seemed like a good idea. However, later on I did quite a few code reviews. Some typical ways to handle checked exceptions appeared:
  1. Exceptions were just ignored i.e. the catch block was empty.
  2. Exceptions are logged. This is also what the default Eclipse code snippet does. The code just swallows the exception. However, developers are supposed to actually handle the exceptions and not just log them. More often than not a closer examination revealed that the exception really was about a serious problem and the program should probably have signaled a failure to the user - and not just continue and log the problem somewhere. This is pretty much the same situation as ignoring return codes in C - which exceptions were supposed to solve.
  3. Sometime the exception is wrapped and rethrown. This is more or less identical to an unchecked exception. The exception is just propagated. Just the type changes, of course - but that might not justify the code written.
Only seldom the exception is really actually handled e.g. by trying an alternative algorithm or returning some kind of default value. You could argue that this is just the fault of the developers who wrote the code. Why did they not implement proper exception handling? However, some facts made me wonder whether this is actually the correct explanation: So apparently checked exceptions might not be such a smart idea after all - otherwise everybody would be using them. And the reason why so much exception handling is implemented poorly might be that developers are forced to write code to handle exceptions - even if there is no sensible way to do so. This is the primary difference between checked and unchecked exceptions: Unchecked exceptions have a sensible default i.e. the exception is just propagated to the next level in the call hierarchy. Checked exceptions lack such default and must therefore be handled in one way or another. So essentially checked exceptions force the developer of the calling code to handle the exception. This makes only sense if it can be handled sensible. In a lot of cases that is not possible. Therefore I believe checked exceptions should hardly be used. In almost any case it is better to rely on an unchecked exception. Then the default is that the exception is propagated if not handled - which is usually the better alternative. Note that it is still possible to handle the exception if needed. I think relying more on unchecked exceptions is primarily a matter of courage. A lot of projects and libraries in the Java space use checked exceptions. They are without a doubt overused - see JDBC's SQLException for example. It is a checked exception but can hardly ever be handled sensible. Not to follow these bad examples truly takes courage. Maybe introducing checked exception is even the greatest mistake in Java's language design.

Labels: ,

 
Bookmark and Share
Comments:
The only advantage I can see is the self documentation of the interface. You see straight away "something can go wrong" without JavaDoc. Good for lazy developers.
But as you already stated: no other major language is using it. That's a sign and presumably a lesson learnt by the C# authors.

Frank
 
Hi Frank,
Thanks a lot for the comment!
However, you can declare RuntimeExceptions in the throws clause which makes sense add you pointed out...
Best regards,
Eberhard
 
I fully agree. Checked exceptions were a bad idea in Java.
Personally I try to catch checked exceptions early and convert them to unchecked exceptions. So my code as as little exposure to them as possible. For my own exceptions I only use unchecked exceptions. Still I document them in the method signature to show they can be thrown. I also use one catch Throwable on the top level to catch and log any exceptions that slipped through.

Christian
 
Oracle could just get rid of checked exceptions. There is AFAIK zero support in the VM for them, they are purely a compiler feature, and getting rid of them would be a backwards compatible change.

In fact there is even a hack to switch them off in javac: http://projectlombok.org/disableCheckedExceptions.html
 
Sorry, I have to disagree. If you design your application properly checked exceptions are a valuable add-on in the Java language. Errors indicated by an exception are a part of the contract of a class. There is a value in unchecked exceptions, but simply throwing an unchecked exception is saying "F*** off". There is no value in throwing an exception from the basement of an application to its roof. Mostly the problem is the missing error handling and error handling design in the application.
 
Hi Oliver,

thanks for the comment! The main reason for the opinion expressed here are code reviews with lots of useless or even dangerous exception handling. So while I agree with you from a theoretical point of view I disagree based on my practical experience.
 
Couldn't agree more. Even when careful error handling is employed, checked exceptions lead to "exception driven development". You end up with more try-catch blocks than actual code. Most of the blocks just wrap and propagate the exception.

Closeable.close() throws IOException, anyone? ;)

In my projects, I generally prohibit the use of checked exceptions.
 
While I get your point on how exception handling is done wrong often, I have to agree with Oliver: You cannot first say that back in the days it was easy to just ignore error codes in languages like C, which led to (checked) exceptions in Java, and then revert to just ignoring exception handling again.
Again, I see the problem, but I don't see how RuntimeExceptions are the solution.
 
@Reinhard
If you use unchecked exception the error cannot be ignored. Unchecked exceptions are either caught or are handled by some generic exception handler e.g. an error page in a web application. So it is not like the return code in C at all.
 
The argumentation in this article is a bit weak. It seems to be sufficient to find just one good checked exception to proof that this language feature is a useful one. So the example I would choose java.nio.file.AccessDeniedException. If I throw this I force my client to handle it. It should be handled in a way that it is shown to the user in some dialog.
I would say the problem in many Java APIs is that they are not really designed from the client's perspective. Since this is difficult when you do a very general API (Spring framework for example) I would agree to use mostly unchecked exceptions in this case. But if you are sitting with the client-side developer and discuss an interface I do like checked exceptions.
 
@Michael Thanks for the comment! As it says in the blog post: "Therefore I believe checked exceptions should hardly be used." - in other words: There might be cases where checked exceptions can make sense i.e. if the error can be handled sensible and handling must be enforced. I am not sure whether your case falls into this category. After all a generic exception handling might be equally useful. Also to design an interface and spell out error conditions unchecked exceptions might be enough - as they can also be listed in the throws clause.
 
Kommentar veröffentlichen

<< Home
J for Java | I for Internet, iMac, iPod and iPad | Me for me

ARCHIVES
Juni 2005 / Juli 2005 / August 2005 / September 2005 / Oktober 2005 / November 2005 / Dezember 2005 / Januar 2006 / Februar 2006 / März 2006 / April 2006 / Mai 2006 / Juni 2006 / Juli 2006 / August 2006 / September 2006 / Oktober 2006 / November 2006 / Dezember 2006 / Januar 2007 / Februar 2007 / März 2007 / April 2007 / Mai 2007 / Juni 2007 / Juli 2007 / August 2007 / September 2007 / Oktober 2007 / November 2007 / Dezember 2007 / Januar 2008 / April 2008 / Mai 2008 / Juni 2008 / August 2008 / September 2008 / November 2008 / Januar 2009 / Februar 2009 / März 2009 / April 2009 / Mai 2009 / Juni 2009 / Juli 2009 / August 2009 / September 2009 / Oktober 2009 / November 2009 / Dezember 2009 / Januar 2010 / Februar 2010 / März 2010 / April 2010 / Mai 2010 / Juli 2010 / August 2010 / Oktober 2010 / Januar 2011 / Februar 2011 / März 2011 / April 2011 / Mai 2011 / Juni 2011 / August 2011 / September 2011 / November 2011 / Februar 2012 / April 2012 / Mai 2012 / April 2013 / Mai 2013 / Juni 2013 / Januar 2015 / Juli 2015 / Februar 2016 /

Links

Twitter
Google +
Slideshare
Prezi
XING
LinkedIn
Das Spring Buch


Feeds

Feedburner


Impressum
Betreiber und Kontakt:
Eberhard Wolff
Leobschützer Strasse 22
13125 Berlin
E-Mail-Adresse: eberhard.wolff@gmail.com

Verantwortlich für journalistisch-redaktionelle Inhalte:
Eberhard Wolff