Java Exceptions are one of my favourite questions to ask during telephone interviews (which I recently covered in some depth here). They’re one of the simpler parts of Java so you should expect most candidates to be able to give good answers. It’s normally easy to weed out those who don’t as not worth your time. However what I really like about Exceptions as interview fodder is that they allow the combination of a technical core java question with an opinion piece. Checked Exceptions are actually a really controversial part of Java and it’s good to see which side of the fence a candidate falls on, or whether they are even aware that the fence is there.
- What is an Exception in Java?
I don’t normally ask this question as it’s so basic but it’s good to make sure you’ve got a standard answer in your pocket. Exceptions are a way to programmatically convey system and programming errors. All exceptions inherit from Throwable. When something goes wrong you can use the throw keyword to fire an exception.
- There are 2 types of exception in Java, what are they and what’s the difference?
It still amazes me how much the “2 types” question throws people (yep, throws, I did it again, another pun). This is as basic as core java gets. If you don’t get this then it tells me that you didn’t learn core java properly (or at all) which will probably act as a shaky base for the rest of your knowledge. Get this answer right.
The two types of exception are checked and unchecked. I’ve heard some strange answers in my time including “Runtime and NullPointerException”! A checked exception is one that forces you to catch it. It forms part of the API or contract. Anyone using code that throws a checked Exception can see that as it is declared on the method and they are forced to handle it using a try/catch block. Unchecked on the other hand does not need to be caught and does not notify anyone using the code that it could be thrown.
- How do I know if an Exception class is checked or unchecked?
All exceptions are checked exceptions except those that inherit from java.lang.RuntimeException.
- What does “finally” do?
Exceptions are caught using a try-catch block. However following the catch you can have a finally block. This block is guaranteed to execute no matter what happens (short of someone pulling out the plug), such as if an Exception is thrown in the catch block. This is really useful to ensure the clean up of resources such as Connections.
- Can I throw multiple Exceptions from the same method? How do I catch them?
Yes you can, they just need listing after the “throws” in the method signature. You can catch them simply using multiple catch blocks, or by catching a parent exception class e.g. you can just catch Exception which will catch all Exceptions. This is in theory bad practice as you lose the nuance of what went wrong and specifically the ability to recover. You can also catch multiple exceptions in a single catch block as of Java 7.
When catching exceptions it is important to do so in order from most specific to least specific. If your catch block catches Exception first and then IOException second, the first catch block will always catch any Exception coming through and the IOException will be rendered useless (and in fact it will cause a compiler error saying the Exception has already been caught)
- What do you think of Checked Exceptions, are they a good thing?
- When you’re writing your own code and you need to throw a custom exception, do you create a checked or unchecked exception?
- C sharp does not have Checked Exceptions. Can you tell me why this might be? Who do you think was right, Java or C sharp?
I love these questions so much. It’s a really good way to stretch a candidate and to see if they understand how to architect systems. Having an appropriate policy on Exceptions is key to maintaining a clean code base, and you’ll quickly figure out who’s thought about the issue and who hasn’t.
A must read before your interview is this interview with the creator of C# and why he didn’t include checked exceptions in the language. The argument in general is that Checked Exceptions cause ugly code in Java. Handling is incredibly verbose, and normally most developers don’t know how to handle them or are too lazy to. This results in empty catch blocks or just log statements. This results in a brittle system where Exceptions get swallowed never to be heard from again and the system can get into a brittle state without telling anyone.
On the positive side for checked, it declares on the API what it’s going to do so people can handle it. This is good if you’re handing out a library. However a lot of developers use this for evil, and control the flow of their system using exceptions. Exceptions are for exceptional circumstances only.
As with most discussion questions the important part is not that the developer agrees with your opinion but that they are capable of forming an opinion and explaining it. I personally fall heavily on the side that Checked Exceptions are terrible and developers misuse them. In my code all checked exceptions get wrapped in an application specific RuntimeException and thrown up the stack where I’ll normally have an Exception Guard to catch and log the issue. However if a candidate say they use Checked Exceptions in their code and can explain why with an understanding of the problems then they get a pass.
Just make sure you’ve thought about where you lie on the issue before you go in for your interview so you can articulate it to the interviewer. And if you’ve never thought about it before, then remember checked exceptions are evil :).