Java: для чего IOEXceptions в readLine BufferedReader ()?
Я могу "зафиксировать" ниже исключения с циклом выгоды попытки, но я не могу понять причину.
- Почему делает часть "in.readLine ()" continuosly, зажигают IOExceptions?
- Какова действительно цель выдать такие исключения, цель, вероятно, не только больше побочных эффектов?
Код и IOExceptions
$ javac ReadLineTest.java
ReadLineTest.java:9: unreported exception java.io.IOException; must be caught or declared to be thrown
while((s=in.readLine())!=null){
^
1 error
$ cat ReadLineTest.java
import java.io.*;
import java.util.*;
public class ReadLineTest {
public static void main(String[] args) {
String s;
BufferedReader in = new BufferedReader(new InputStreamReader(System.in));
// WHY IOException here?
while((s=in.readLine())!=null){
System.out.println(s);
}
}
}
5 ответов
Основная идея заключается в том, что BufferedReader делегирует другому типу Reader, поэтому он передает это исключение.
Этот другой тип читателя может читать из какого-то изменчивого внешнего ресурса, скажем, из файловой системы в случае FileReader. Чтение из файловой системы может завершиться неудачей по многим причинам в любое время. (Ситуация еще хуже, если Читатель получает базовые данные из сетевого потока). Файл может быть удален из-под вашего носа (в зависимости от файловой системы и ОС).
Поскольку вы не можете предсказать, что произойдет с кодом, вы получаете проверяемое исключение - смысл в том, что API говорит вам, что вы должны подумать о том, что эта операция может не сработать, даже если в вашем коде все в порядке.
- Он не будет «постоянно зажигать» их, он просто может бросать их каждый раз, когда вы его вызываете. В вашем случае, если он что-то выдает, это означает, что что-то пошло не так со стандартным вводом.
- Цель состоит в том, чтобы гарантировать, что вы, программист, использующий API, справитесь с проблемой, поскольку обычно предполагается, что это проблема, которую можно устранить, хотя в вашем конкретном случае она будет фатальной для всей вашей программы.
BufferedReader.readLine () объявлен как потенциально вызывающий исключение, см. https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/BufferedReader.html#readLine ()
Вам нужно либо поймать его, либо объявить ваш основной метод как генерирующий IOException.
Т.е. либо сделать так:
try {
while((s=in.readLine()) != null){
System.out.println(s);
}
} catch(IOException e) {
// Code to handle the exception.
}
Или
public static void main(String[] args) throws IOException { ...
IOException - это проверенное исключение. Вы должны либо поймать его, либо бросить в вызывающий метод. Проверенные исключения вызываются внешними факторами, такими как отсутствующий файл, сбой диска или что-то еще, от чего вы не можете избавиться в своем программном коде.
Однако непроверенные исключения, такие как ArrayIndexOutofBoundsException, вызваны неправильной логикой в программе. Вы можете обойти его, используя условие if вне вашего дефектного кода (что-то вроде if currIndex>array.length). В случае проверяемого исключения такого условия нет
Он выбрасывается, если при вводе/выводе возникает исключительная ситуация, например, источник потока больше недоступен.
В таких случаях ваша программа должна уметь восстанавливаться. Либо путем перечитывания источника, либо путем использования некоторых значений по умолчанию, либо путем предупреждения пользователя о проблеме.
Вы вынуждены поймать его, потому что это проверяемое исключение, а вы должны уметь восстанавливаться после таких исключений.
Конечно, у вас есть возможность объявить, что текущий метод выбрасывает это исключение вызывающим методам, но в конечном итоге вам придется его поймать (или позволить ему разразиться до главного метода, когда оно просто выводится на консоль и выполнение программы прекращается)