Java checked exceptions

Question

I'm trying to understand checked exceptions in Java and have the following query.

Is the following correct: If a method has the potential to throw a checked exception, of any type, that exception must either be

1. declared using the throws keyword, or
2. caught by the respective method.

If the above is correct, does this mean that I need to understand every single checked exception that is built in to Java so that I know whether my method will have the potential to throw that exception? Or should I just attempt to compile my code and then amend my code based on the compile-time errors?

Answer 1

If the above is correct, does this mean that I need to understand every single checked exception that is built in to Java [...]?

Yes, your statements are correct, but no one expects you to know of all potential checked exceptions when programming. And you don't have to if you have a compiler, or better, an IDE at hand.

Either you go back and forth between compiler output and code as you suggest in your question, or you install an IDE such as Eclipse which gives you direct notifications if you violate the rule:

Answer 2

does this mean that I need to understand every single checked exception that is built in to Java

I assume you are using some IDE (eg. Eclipse) - if not, you should get one ASAP.

Then, the IDE pretty much continuously compiles the code, so when there's a problem, you will get a red underline near it, and a tooltip bubble telling you what's wrong - eg "Missing throws".

Therefore, your second assumption is basically correct, it just happens behind the scenes:

Or should I just attempt to compile my code and then amend my code based on the compile-time errors?

So no, you don't need to learn all the exceptions.

Also, all checked Exceptions extend Exception, so if you have access to the source, you can check what they are based on. Non-checked exceptions extend RuntimeException.

Rule of thumb: If it's something with I/O, it's usually checked. That's the most common type of exception you will encounter.

Answer 3

whenever you use a method (whether your own or In-built) if you closely follow its method signature, if the method throws some exception you need to throw/handle it explicitly in your code

In this way you will not need to memorize all the exceptions and you will know which exceptions to handle where.

To make life easy use some IDE like eclipse

hope this helps!

Good luck!

Answer 4

If the above is correct

It is...

[...] does this mean that I need to understand every single checked exception that is built in to Java so that I know whether my method will have the potential to generate that exception? Or should I just attempt to compile my code and then amend my code based on the compile-time errors?

Use an IDE! You don't need to intimately know ALL of them.

What you do want to check however is the hierarchy (ie, check the javadoc! That should be a Pavlovian reflex); since exceptions are classes, they inherit one another and, for instance, FileSystemException is a portmanteau exception of java.nio.file to signal a filesystem related problem and it inherits IOException. Catch it before IOException if you want to treat it specially.

As a general rule, catch more specific exceptions first.

Also, DO NOT catch Exception. Never. The problem is that RuntimeException, which is the base exception for unchecked exceptions, inherits Exception, meaning that if you catch Exception you catch all unchecked exceptions. You want to rethrow unchecked ones:

try {
    something();
} catch (RuntimeException unchecked) {
    throw unchecked;
} catch (Exception e) {
    // deal with e
}

Answer 5

Yes you need to know every exception..however if u know super class of that exception than you u don't need to know the subclass of it...for e.g..FileReader throws a exception called FileNotFoundException Since FileNotFoundException is a subclass of IOException, we can just specify IOException in the throws list and make the above program compiler-error-free.