The last time we met, we got down and dirty with basic exception handling. And, to be frank, that stuff was pretty straight-forward. If you just think about it for a second, it becomes clear how you should order your catch statements. What is less clear is why pizza sauce is on the condiment aisle at my local grocery store, not the pasta aisle. Come on, how on earth am I supposed to find that? What is also less clear is some of the specifics of exception handling, specifically checked versus unchecked exceptions.
I like to read a few different development forums, mainly to reinforce the idea that, while there are lots of better coders out there, few of them can use semicolons as well as I can. A recent topic I read dealt with technical interviews for a Java position, and how candidates were consistently stumped by a question on the differences between checked and unchecked exceptions. I'm familiar with the terms, but if I had to answer the question, I'd probably end up babbling about how unchecked exceptions are far less likely to come from Prague (okay, that one doesn't work as well when the words are spelled out). I know that you handle those checked and unchecked exceptions differently, but I think I'd have a hard time if someone put me on the spot. And so, as the grand duchy of Vlogsylvania, now seems like the opportune time to attack this subject.
As far as I know, Java is the only language where you have to differentiate between checked and unchecked exceptions (here's an explanation on why the C# team elected to diverge from this). I've seen the difference between the two explained a few different ways, but here's the one that made the most sense to me: checked exceptions are subclasses of Exception, while unchecked exceptions are subclasses of RuntimeException. With a little bit of deduction, we can figure out what the hell that actually means.
If unchecked exceptions are runtime exceptions, then the compiler isn't involved at all. You won't get any errors about not handling these exceptions, because the compiler can't know that they could arise; no sir, that's a runtime issue. Conversely, checked exceptions have nothing to do with runtime exceptions, and as such, are compiler issues. Since they're compiler issues, you can't ignore them; there's going to be some code involved. Specifically, you must declare each checked exception that a method throws. Then, the calls to that method must either catch the exception or throw it again. To put it simply, checked exceptions are the ones you anticipate and can do something about. Enough gobbledy-gook, let's hop aboard the Example Train.
//and now the caller.
public static void main(String[] args)
{
Alf littlehairydude = new Alf();
try
{
littlehairydude.EatCat();
}
catch (CatNotFoundException ex) //look at what we're catching.
{
system.out.println("Someone alert Willie!");
}
}
From a micro perspective, that's very cool. By declaring the kind of exceptions the method can throw, you force the implementor to plan ahead and handle any errors in a graceful manner. And in small doses, I bet this works really well. In large systems however, it gets very cumbersome. Not only must you deal with the fact that your coworker smells like rotten beets and continuously rambles on about who'd win in a fight between Uhuru and Lando Calrissian, you have to code to handle every one of his stinking exceptions. Not only that, but all the while, you have to hope he's keeping his checked and unchecked exceptions properly segregated.
There are a lot of arguments against checked exceptions (the seminal piece here), but nevertheless, they represent some neat programming power. As Spider Man taught us, with great power comes great responsibility. For some, that's no problem. For others, who man the frontlines of the great Uhuru vs. Calrissian debate, it's not quite that easy. Like the road signs say, proceed with caution.