Я знаю, что FileNotFound является проверенным исключением, но хотя это и так, это исключение будет возникать только во время выполнения. Это больше похоже на арифметическое исключение (непроверенное).
Независимо от того, отмечен он или нет, исключение произойдет только во время выполнения.
Мой вопрос заключается в том, почему мы называем связанные с FileNotFound/IO/DB вещи проверенным исключением?
Пожалуйста, поделитесь со мной своими ценными мыслями :)
Исключения всегда возникают только во время выполнения. Разница возникает при обработке исключения.
Отмеченный или неотмеченный означает, будет ли он принудительно обрабатываться во время компиляции или будет идентифицирован только при обнаружении во время выполнения.
Если исключение проверено, это означает, что у компилятора есть способ определить, может ли произойти исключение или нет. и всякий раз, когда вы его компилируете, вы будете вынуждены обрабатывать проверенное исключение, и благодаря этому вероятность исключений во время выполнения будет уменьшена.
Во время обработки файла компилятор не проверяет, присутствует файл или нет, он просто проверяет, обработали ли вы fileNotFoundException или нет, потому что когда вы имеете дело с файлом, шансы столкнуться с этим исключением очень высоки, и вы должны обрабатывать его в своем код. для арифметического исключения нет способа найти его во время компиляции. и, таким образом, он остается непроверенным.
NullPointerException или ArithmeticException обычно не должно происходить в готовой, правильной программе. Вы можете обрабатывать их только с проверкой перед if, чтобы увидеть, делитесь ли вы на 0 или объект равен null, и тогда вы уверены, что это исключение не будет выбрано. Каждый раз, когда обработка этих исключений может сделать код менее читаемым.
Теперь вы можете утверждать, что можете сделать то же самое для FileNotFoundException, просто проверив, существует ли файл, прежде чем что-либо делать. Но многие конструкторы или методы, которые ожидают File, также поддерживают String, из которого затем создается файл. Я думаю, это вопрос того, где вы проводите линию, если у вас всегда есть только метод File и никогда не поддерживается String, я бы тоже добавил его к непроверенным, я думаю.
Другими словами: если выдается FileNotFoundException, то это может быть желаемым поведением и управлять потоком вашей программы, но NullPoinerException на самом деле не следует использовать для этого.
Все исключения могут происходить только во время выполнения :) Разница между исключениями Checked и Unchecked заключается в том, что компилятор заставляет вас обрабатывать исключения checked или добавлять их в сигнатуру метода, фактически заставляя вызывающую программу делать то же самое (обрабатывать/возвращать ).
Они позволили ему быть проверенным исключением, потому что пользователь может «восстановиться» от этого исключения, обработав его. Например, пользователь может указать другой каталог на случай возникновения этого исключения.
Отмеченные исключения заставляют пользователей явно обрабатывать их, они используются для «исправимых» исключений, когда пользователь может изящно справиться с ситуацией.
Давайте возьмем 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 не будет корректно закрыт, и это утечка ресурсов.
