Perché a volte compare throws e a volte no?

[peruzzo]

Perché negli esempi sul libro a volte compare throws e a volte no?

Qui ad esempio compare:

/* Display a text file. 
   To use this program, specify the name 
   of the file that you want to see. 
   For example, to see a file called TEST.TXT, 
   use the following command line. 
 
   java ShowFile TEST.TXT 
 
   This variation wraps the code that opens and 
   accesses the file within a single try block. 
   The file is closed by the finally block. 
*/ 
 
import java.io.*; 
 
class ShowFile { 
  public static void main(String args[]) 
  { 
    int i; 
    FileInputStream fin = null; 
 
    // First, confirm that a file name has been specified. 
    if(args.length != 1) { 
      System.out.println("Usage: ShowFile filename"); 
      return; 
    } 
 
    // The following code opens a file, reads characters until EOF 
    // is encountered, and then closes the file via a finally block. 
    try { 
      fin = new FileInputStream(args[0]); 
 
      do { 
        i = fin.read(); 
        if(i != -1) System.out.print((char) i); 
      } while(i != -1); 
 
    } catch(FileNotFoundException e) { 
      System.out.println("File Not Found."); 
    } catch(IOException e) { 
      System.out.println("An I/O Error Occurred"); 
    } finally { 
      // Close file in all cases. 
      try { 
        if(fin != null) fin.close(); 
      } catch(IOException e) { 
        System.out.println("Error Closing File"); 
      } 
    } 
  } 
}

e qui no:

/* Copy a text file. 
   To use this program, specify the name 
   of the source file and the destination file. 
   For example, to copy a file called FIRST.TXT 
   to a file called SECOND.TXT, use the following 
   command line. 
 
   java CopyFile FIRST.TXT SECOND.TXT 
*/ 
 
import java.io.*; 
 
class CopyFile { 
  public static void main(String args[]) throws IOException  
  { 
    int i; 
    FileInputStream fin = null; 
    FileOutputStream fout = null; 
 
    // First, confirm that both files has been specified. 
    if(args.length != 2) { 
      System.out.println("Usage: CopyFile from to"); 
      return; 
    } 
 
    // Copy a File. 
    try { 
      // Attempt to open the files. 
      fin = new FileInputStream(args[0]); 
      fout = new FileOutputStream(args[1]); 
 
      do { 
        i = fin.read(); 
        if(i != -1) fout.write(i); 
      } while(i != -1); 
 
    } catch(IOException e) { 
      System.out.println("I/O Error: " + e); 
    } finally { 
      try { 
        if(fin != null) fin.close(); 
      } catch(IOException e2) { 
        System.out.println("Error Closing Input File"); 
      } 
      try { 
        if(fout != null) fout.close(); 
      } catch(IOException e2) { 
        System.out.println("Error Closing Output File"); 
      } 
    } 
  } 
}

Chi mi spiega perché nel primo caso throws è necessario?

[schumy2000]

Ma com'è che il tuo libro non le chiarisce queste cose ?!? Ma lo leggi ?!?
E' inconcepibile...ma che libro hai preso... (a parte miliardi di guide on line che chiariscono le cose molto meglio del tuo libro)

Cmq prendo un esempio da Stackowerflow, visto che d'inglese non ne capisci una mazza (e per un programmatore è il minimo sapere almeno l'inglese tecnico o almeno sapere usare google translator)

Throws serve per portare le eccezioni al blocco chiamante senza bisogno di inserire il try catch all'interno del metodo

//nel costruttore o in qualunque altro metodo
public NomeooggettoCostruttore(){
...
...
 try{
     method();
 }catch(IOException) {}
  catch(Exception) {}
...

}

public void method() throws IOException, Exception{
   BufferedReader br = new BufferedReader(new FileReader("file.txt"));
}

se non c'era il trows avresti dovuto mettere il try catch dentro il metodo "method"

[Alex'87]

Originariamente inviato da peruzzo
Perché negli esempi sul libro a volte compare throws e a volte no?

Chi mi spiega perché nel primo caso throws è necessario?

La spiegazione la trovi nel capitolo delle eccezioni...

[peruzzo]

Grazie per il messaggio però non capisco perché usare throws nel codice quando dentro CopyFile ci sono già tutti blocchi try e catch. In pratica non capisco quale try e catch sostituisce? Se dentro CopyFile sono incorporati metodi già inclusi in blocchi try catch quale eccezione potrebbe mai dare origine il metodo main()? La differenza tra i 2 codici è che uno oltre che a leggere scrive anche ma fout.write(i) è già dentro un try.

[Alex'87]

Originariamente inviato da peruzzo
Grazie per il messaggio però non capisco perché usare throws nel codice quando dentro CopyFile ci sono già tutti blocchi try e catch. In pratica non capisco quale try e catch sostituisce? Se dentro CopyFile sono incorporati metodi già inclusi in blocchi try catch quale eccezione potrebbe mai dare origine il metodo main()? La differenza tra i 2 codici è che uno oltre che a leggere scrive anche ma fout.write(i) è già dentro un try.

L'esempio è fatto veramente male a mio pare... O catturi le eccezioni o le rilanci. Oppure ne catturi una parte e ne rilanci altre, dipende da cosa vuoi fare.

Quando usare catch? Quando all'interno del metodo puoi fare qualcosa per rimediare. Esempio:

...
String s = args[0];

int num;

try {
  num = Integer.parseInt(s);
} catch (NumberFormatException ex) {
  System.err.println(s + " non e' un numero valido, proseguo con un valore di default");
  num = DEFAULT_VALUE;
}

...

Facciamo finta che questo sia l'inizio di un programma da linea di comando che a bisogno di un intero in input per lavorare. Possiamo decidere che nel caso in cui il valore passato non sia valido, ne uso uno di default in modo da non crashare. Ecco quindi che l'eccezione la catturo.


Quando usare throws? Quando, nel punto in cui si solleva l'eccezione, non puoi fare nulla per rimediare. Ad esempio,

public String readFile(String fileName) throws IOException {
  StringBuilder sb = new StrinBuilder();
  FileInputStream fin = new FileInputStream(fileName); 
 
  int i;
  while ((i = fin.read()) != -1)
    sb.append((char) i);
  }

  return sb.toString();
}

Ora, read() potrebbe lanciare una IOException (disco pieno in caso di scrittura, permessi non sufficienti, problemi durante la scrittura, ecc). Cosa può fare questo metodo per rimediare? Nulla. La cosa più ragionevole è lasciare che l'eccezione risalga lo stack trace finché non trova qualcuno in grado di gestirla.

[schumy2000]

Concordo con Alex l'esempio è fatto veramente male...

[Alex'87]

omg ho visto ora di aver scritto un orrore grammaticale

[peruzzo]

Ancora 2 domande:

1) Convenite con me che il pezzetto "throws IOException" è ridondante è può essere rimosso?

2) Ho notato che il mio libro, tra le diverse varianti di quel codice (ce ne sono parecchie...) usa throws quando nel codice c'è write(), non è che c'è qualcosa che ci sfugge?

A presto

[Alex'87]

Originariamente inviato da peruzzo
1) Convenite con me che il pezzetto "throws IOException" è ridondante è può essere rimosso?

Dipende, come ti ho già detto, un'eccezione o la catturi o la rilanci. Se la catturi l'eccezione X non ha senso usare throws X, se usi throws X non ha senso fare il catch di X.

Originariamente inviato da peruzzo
2) Ho notato che il mio libro, tra le diverse varianti di quel codice (ce ne sono parecchie...) usa throws quando nel codice c'è write(), non è che c'è qualcosa che ci sfugge?

Cosa ci sfuggirebbe?
Hai letto il mio messaggio precedente?

[peruzzo]

Ma Alex'87 non puoi scrivermi dipende alla prima domanda! Se il codice ha qualche utilità si lascia diversamente si toglie e il fatto che il codice sia un brutto esempio è un altro discorso! Io ripeto non vedo nessuna utilità ma temo che mi sfugga qualcosa, Herbert Schildt non credo sia un fesso...