Java: Para que serve o IoExceptions no BufferredReader's ReadLine ()?

Question

Posso "consertar" a exceção abaixo com um loop de tentativa, mas não consigo entender o motivo.

1. Por que a parte "in.ReadLine ()" acende continuamente o IoExceptions?
2. Qual é realmente o objetivo de lançar tais exceções, o objetivo provavelmente não apenas mais efeitos colaterais?

Código e ioeExceptions

$ 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);
  }
 }
}

Answer 1

A idéia básica é que um leitor de buffers delega a um tipo diferente de leitor, para que esteja passando essa exceção.

Esse tipo de leitor diferente pode ler a partir de algum tipo de recurso externo volátil, digamos um sistema de arquivos no caso do FileReader. Uma leitura do sistema de arquivos pode falhar por muitos motivos a qualquer momento. (A situação é pior se o leitor estiver obtendo seus dados subjacentes de um fluxo de rede). O arquivo pode ser excluído por baixo de você (dependendo do sistema de arquivos e do sistema operacional envolvido).

Como você não pode prever o que acontecerá com o código, você obtém uma exceção verificada - o ponto é que a API está lhe dizendo que você deve pensar no fato de que essa operação pode não dar certo, mesmo que não haja nada de errado com seu código.

Answer 2

1. Não "não os inflamará continuamente", apenas poderia Jogue -os cada vez que você invoca. No seu caso, se lança algo, isso significa que algo deu errado com sua entrada padrão.
2. O objetivo é garantir que você, o programador, usando a API, lide com o problema, pois, em geral, assume -se que seja um problema recuperável - embora, no seu caso específico, seja fatal para todo o seu programa.

Answer 3

BufferedReader.readLine() é declarado como potencialmente jogando uma exceção, veja: http://java.sun.com/j2se/1.3/docs/api/java/io/bufferedreader.html#readline ()

Você precisa pegá -lo ou declarar seu método principal como lançar a ioexception.

Ou seja, faça isso:

try {
    while((s=in.readLine()) != null){
        System.out.println(s);
     }
} catch(IOException e) {
    // Code to handle the exception.
}

Ou

public static void main(String[] args) throws IOException { ...

Answer 4

IoException é a Exceção verificada. Você deve pegá -lo ou jogá -lo no seu método de chamada. Exceções verificadas são causadas por atores externos, como um arquivo ausente, falha no disco ou qualquer coisa da qual você não possa se recuperar no código do programa.

No entanto, uma exceção desmarcada, como ArrayIndexoutOfBoundSexception, é causada pela lógica defeituosa no programa. Você pode subvertê -lo usando uma condição IF fora do seu código defeituoso (algo como se currrindex> Array.length). Não existe tal disposição em caso de exceção verificada

Answer 5

É jogado se ocorrer uma situação excepcional com a E/S, por exemplo, a fonte do fluxo não estiver mais disponível.

Nesses casos, seu programa deve ser capaz de se recuperar. Reler a fonte ou usando alguns padrões ou alertando o usuário sobre o problema.

Você é forçado a catch É, porque é uma exceção verificada e você deve se recuperar delas.

Obviamente, você tem a opção de declarar que o atual menthod throws Esta exceção aos métodos de chamadas, mas você terá que pegá -lo eventualmente (ou deixá -lo borbulhar com o método principal, quando simplesmente é impresso no console e a execução do programa para)

Answer 6

Usando Scanner Para leitura, os arquivos (ou outro tipo de entrada) podem ser extremamente ineficientes em situações de média/larga escala. Se você tem preocupações de desempenho ler milhares ou milhões de linhas, eu recomendo fortemente que você use BufferredReader aula em vez disso. Um exemplo de uso do BufferErader para ler linhas de System.in é exibido abaixo:

public static void main(String[] args) throws Exception {

    String line = null;
    BufferedReader br = new BufferedReader (new InputStreamReader(System.in));

    try {
        /* This is protected code. If an problem occurs here, catch block is triggered */
        while ( (line = br.readLine()) != null ){
            System.out.println(line); 
        }
    }
    catch (IOException e){
        throw new IOException("Problem reading a line",e);
    }
}

IoException deve ser usado em try/catch bloco para que possa ser acionado sempre que o código protegido dentro try sofre de um comportamento "excepcional", como um erro. Java tem suas próprias exceções que são lançadas quando a situação semelhante acontece. Por exemplo, ArrayIndexOutOfBoundsException é jogado quando você define uma matriz a de tamanho n E você tenta acessar a posição a[n+1] em algum lugar do seu código. Como ArrayIndexOutOfBoundsException, Existem muitas outras classes de exceção que você pode jogar e personalizar com suas próprias mensagens. O código adequado a uma exceção deve ser colocado na zona protegida no bloco de tentativas. Quando a exceção ocorre nesse bloco, a exceção será tratada no bloco de captura com ele.

Olha que você não precisa construir if/else Declarações para antecipar a situação do erro e lançar uma exceção para cada caso. Você só precisa associar possíveis situações de exceção entre try e catch quadra. Veja mais sobre Tente/Catch Blocks é incentivado para programação segura.