3

I have been re-factoring some Java code lately... I have found that there were many RuntimeExceptions being thrown (i.e. unchecked exceptions). I have created my own checked exception and replaced each instance of these RuntimeExceptions with my own exception. Then, this forced me to check the exceptions.

With that said, I find checked exceptions better because another developer will make sure to handle the exceptions... Instead of the program just eating the exception without displaying anything to the user.

I have read many articles on unchecked vs. checked exceptions.. However, I still feel like I checked exceptions more because it reduces human error.

How poor of programming is it too mainly use checked exceptions? Has anyone else felt like they like checked exceptions more than unchecked exceptions?

Chris Bolton
  • 2,162
  • 4
  • 36
  • 75
  • 2
    I like unchecked exceptions, so that way I can print to the console without catching 4 different exceptions. One line becomes 30 – Kon Feb 12 '15 at 19:47
  • You should go into the detail cases. – chenrui Feb 12 '15 at 19:50
  • 1
    As you say yourself, there are tons of arguments all over the Internet about this question. While Robert C Martin declares "the debate is over", you should use unchecked exceptions, I agreed for so long until I was bitten badly by and caught by surprise while not catching an exception. The production code just crashed. So I think it is still good question, but the answers are all out there, not the least: http://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html – Harald Feb 12 '15 at 19:58
  • I'm not a big fan of checked exceptions, especially when doing async programming. One of my prime examples of bad checked exceptions is MalformedURLException... How are you ever going to handle this - it's just the result of bad input... just like NumberFormatException which is unchecked – ControlAltDel Feb 12 '15 at 19:58
  • @Harald Those are the kind of things I want to avoid... I have seen in production that when a user clicks a button.... Nothing happens! It is because the code is just ignoring the unchecked exception... I don't see how this is a good thing? Sure people will say get better programmers... But no great programmer is perfect. Also, thank you for the URL. Good stuff! – Chris Bolton Feb 12 '15 at 20:01
  • 1
    More here: https://books.google.de/books?id=_i6bDeoCQzsC&lpg=PT241&ots=eo4NEm2g_4&dq=robert%20c%20martin%20%22the%20debate%20is%20over%22&hl=de&pg=PT241#v=onepage&q=robert%20c%20martin%20%22the%20debate%20is%20over%22&f=false – Harald Feb 12 '15 at 20:04
  • @ChrisBolton in my experience, checked exceptions are more often the cause of such problems than unchecked ones. If an unchecked exception is thrown, it bubbles up the stack and causes an error page with a stack trace to be displayed. The user and the developer are immediately aware something went bad. When a method throws a checked exception, it goes is your way: you can't implement the interface anymore, you can't use it in a lambda anymore, it clutters the API. Most newbies, in that case, choose to catch and ignore (or log) the exception, as if nothing happened. – JB Nizet Feb 12 '15 at 20:09
  • Continued: The world has decided: checked exceptions aren't used anymore: all new APIs (javax.time, JPA, etc.) don't use checked exceptions. And the use of lambdas in Java 8 will discourage the use of checked exceptions even more. – JB Nizet Feb 12 '15 at 20:11
  • 1
    Arg for unchecked: http://stackoverflow.com/questions/6591470/checked-vs-unchecked-exceptions-in-service-layer/6592444#6592444 –  Feb 12 '15 at 20:12
  • @WillieWheeler couldn't agree more. – JB Nizet Feb 12 '15 at 20:14
  • @JBNizet I have seen this with checked exceptions also... Where noobs don't even have anything in the catch clause of the exception. So bad! But I am not on Java 8 yet... Will be in the next couple of months which I believe will help alot! – Chris Bolton Feb 12 '15 at 20:16
  • @Chris: You say "I find checked exceptions better because another developer will make sure to handle the exceptions". That is the traditional view. For about ten years now though people have come to see that as a serious *dis*advantage, because too many developers are horrible at handling exceptions. Much more systematic and *stable* to let the exceptions bubble up. –  Feb 12 '15 at 20:21
  • @WillieWheeler So I guess the decision is to decide if we want the developer to not acknowledge that there is an exception there or to acknowledge but ignore in the catch clause? – Chris Bolton Feb 12 '15 at 20:23
  • 1
    @ChrisBolton that's exactly what I'm saying: using checked exceptions force developers to handle them, and in 90% of the case, what they do to handle them is the wrong thing to do. That doesn't happen with unchecked exceptions, because they're not forced to handle them and thus do the right thing: let the exception bubble up the stack. – JB Nizet Feb 12 '15 at 20:24
  • @JBNizet From common consensus, this seems like the correct thing to do... I just have this feeling of it being wrong. But thank you for your input! – Chris Bolton Feb 12 '15 at 20:30

2 Answers2

5

my recommendation, although different people will have different opinions about this, is to:

  • use checked exceptions for exceptional conditions that should be handled by what you consider part of your application logic, e.g: user typed in a non existing user name to log in, user tried to save and item beyond the limit allowed for her subscription, etc. That way the client of the code that finds the exceptional condition is forced to at least acknowledge the fact that the condition might occur and hopefully will handle it in the most appropriate way
  • use unchecked exceptions to fail early and noisily under circumstances not under your control and from which you cannot recover with application logic, e.g: your function receives the wrong parameters as arguments: sounds like the perfect scenario to throw an 'illegal argument exception', which is a runtime exception in most of programming languages out there
Francisco Meza
  • 875
  • 6
  • 8
  • Also note that you can wrap a checked exception in a RuntimeException to bubble up through layers, and then - when you are ready in your own code - unwrap the checked exception and handle it. This allows checked exceptions to propagate through iterators and customized collection methods. – Thorbjørn Ravn Andersen Feb 12 '15 at 20:30
4

Checked exceptions look great upfront, but in practice they simply do not fix the problems they are designed to fix (more details here https://arpytoth.com/2016/04/08/the-problem-with-checked-exceptions/).

Java doesn’t force you to handle the exceptions, it just forces you to acknowledge precisely which exceptions might pass through. Most developers catch them using an empty block or let exceptions pass through using the throws clause. That will decrease the code quality in general, by making it more verbose, complex and sometimes hard to test, without any significant benefits. Also note that Java's new features does not play nice with checked exceptions either (for example lambda expressions). My advice would be to avoid checked exceptions and use runtime instead.

Arpad Toth
  • 231
  • 2
  • 6