Почему FileNotFoundException проверяется как исключение?

Отмеченные исключения вынуждают пользователей явным образом обрабатывать их, они используются для «восстанавливаемых» исключений, когда пользователь может корректно справиться с ситуацией.

Возьмем FileNotFound - обычно он выдается, когда файл отсутствует, и ниже приводится связанная с ним идиома программирования:

FileInputStream fis = null;
try {
    fis = new FileInputStream(new File(""));
} catch (FileNotFoundException e) {
    e.printStackTrace();
} finally {
    try {
        fis.close();
    } catch (IOException e) {
        e.printStackTrace();
    }
}

Здесь проверенное исключение заставляет меня объявить его в блоке try / catch, где я могу аккуратно закрыть fis, даже если есть исключение.

Теперь представьте, что FileNotFound - исключение времени выполнения, код гипотетически будет выглядеть так:

FileInputStream fis = null;
fis = new FileInputStream(new File(""));
fis.close();

Теперь, если это вызывает исключение времени выполнения, которое вам не нужно обрабатывать во время компиляции, ваш fis не будет корректно закрыт, и это будет утечка ресурсов.

Они позволили этому исключению быть проверенным, потому что пользователь может «восстановиться» после этого исключения, обработав его. Например, пользователь может указать другой каталог в случае возникновения этого исключения.

Все исключения могут происходить только во время выполнения :) Разница между исключениями Checked и Unchecked в том, что компилятор заставляет вас обрабатывать checked исключения или добавлять их в сигнатуру метода, фактически заставляя вызывающего сделать то же самое (обработать / перебросить).

NullPointerException или ArithmeticException обычно не должно происходить в законченной правильной программе. Вы можете справиться с ними, просто проверив перед этим с помощью if, чтобы увидеть, если вы делите на 0 или объект равен null, и тогда вы уверены, что это исключение не будет создано. Каждый раз обработка этих исключений может сделать код менее читабельным.

Теперь вы можете утверждать, что вы можете сделать то же самое для FileNotFoundException, просто проверив, существует ли файл, прежде чем что-либо делать. Но многие конструкторы или методы, которые ожидают File, также поддерживают String, из которого затем создается файл. Думаю, это вопрос того, где вы проводите линию, если у вас всегда есть только метод File и никогда не поддерживает String, то я бы добавил его и к непроверенным методам, я думаю.

Другими словами: если выбрано FileNotFoundException, то это может быть желаемое поведение и управлять потоком вашей программы, но NullPoinerException действительно не следует использовать для этого.