Much has been written recently about the value that checked exceptions add, or subtract, from Java.
Some programmers feel that checked exceptions help them build robust applications. Others find that
checked exceptions are an annoyance that hinders their productivity. In this article, Java's
creator James Gosling voices his opinions about checked exceptions and error handling.

In this interview, which will be published in multiple installments, James Gosling talks about many aspects
of programming.

In Part I: Analyze this!, Gosling describes the ways in which Jackpot
can help programmers analyze, visualize, and refactor their programs.

In this installment, Gosling talks about how to build solid apps, organize your catch clauses,
scale checked exceptions, and deal with failure.

Creating Solid Software

Bill Venners: In your weblog, you wrote:

Lots of newbie's coming in from the C world complain about exceptions and the fact that
they have to put exception handling all over the place—they want to just write their code.
But that's stupid: most C code never checks return codes and so it tends to be very fragile.
If you want to build something really robust, you need to pay attention to things that can
go wrong, and most folks don't in the C world because it's just too damn hard.

One of the design principles behind Java is that I don't care much about how long it
takes to slap together something that kind of works. The real measure is how long it
takes to write something solid.

What does "solid" mean?

James Gosling: Solid means you can run the software day in and day
out. When the usual crazy things happen, the software survives. The software deals with
the problems. If you change the system configuration around, the system, as much as
possible, copes—or at least recognizes when things are wrong.

One of the traditional things to screw up in C code is opening a data file to
read. It's semi-traditional in the C world to not check
the return code, because you just know the file is there, right? So you just open the file
and you read it. But someday months from now when your program is in deployment,
some system administrator reconfigures files, and the file ends up in the wrong place.
Your program goes to open the file. It's not there, and the open call returns you an error
code that you never check. You take this file descriptor and slap it into your file
descriptor variable. The value happens to be -1, which isn't very useful as a file
descriptor, but it's still an integer, right? So you're still happily calling reads. And as far
as you can tell, the world is all rosy, except the data just isn't there.

Problems like that are really hard to test for. It is really hard to test the unlikely things, if
only because the unlikely things never really occur to you. In this example, the
programmer will think, "Well of course the file is there. Why would anybody not have
the file there?"

A programming language can't solve all the problems. A language can't guarantee that no
matter how screwed up the environment gets the program will survive. But anything the
language can do to increase the probability that programs will be reasonably graceful
under fire is a good thing. For example, just making people at least willfully ignore return
codes helps. In Java you can ignore exceptions, but you have to willfully do it. You can't
accidentally say, "I don't care." You have to explicitly say, "I don't care."

Bill Venners: You don't have plausible deniability.

James Gosling: Yeah, there's no plausible deniability when it comes to
checked exceptions.