This chapter is from the book
This chapter is from the book
This chapter is from the book
Checked Exceptions
One of the dangers of exceptions is what happens if you throw an exception but no one catches it. The program terminates, that’s what happens. But you’d like to control when the program terminates unexpectedly, printing out information necessary to diagnose the situation and telling the user what has happened.
Exceptions that are thrown but not caught are an even bigger risk when different people write the code that throws the exception and the code that catches the exception. Any missed communication results in an abrupt and impolite program termination.
To avoid this situation, Java has checked exceptions. These are declared explicitly by the programmer and checked by the compiler. Code that is subject to having a checked exception thrown at it must either catch the exception or pass it along.
Checked exceptions come with considerable costs. First is the cost of the declarations themselves. These can easily add 50% to the length of method declarations and add another thing to read and understand along the levels between the thrower and catcher. Checked exceptions also make changing code more difficult. Refactoring code with checked exceptions is more difficult and tedious than code without, even though modern IDEs reduce the burden.