Newsgroup: it.comp.java
Titolo: Costruttori, eccezioni e cleanup operation

Salve!
Sto studiando java su Thinking in Java, e spesso mi trovo in disaccordo con
l'autore, cosa strana visto che io sono un novizio e lui un espertone :-D
Cosi' chiedo a voi di dirmi chi e' che sbaglia fra noi due :)
Thinking in Java asserisce che l'uso di eccezioni e' pericoloso nel caso dei
costruttori, in quanto un eccezione generata in un costruttore blocca
l'esecuzione di eventuali operazioni extra di pulizia dell'oggetto.
Es. apertura di un file, l'operazione extra e' quello di chiudere il file.
Secondo me il problema non e' solo dei costruttori, ma di qualunque metodo.
Quel che cambia è solo che, se l'eccezione viene generata da un metodo, so
per certo che l'oggetto esiste, mentre nel caso di costruttore l'eccezione
potrebbe avvenire proprio nell'atto di creare l'oggetto.
Voi che dite?
riporto di seguito l'esempio proposto dal libro
// Paying attention to exceptions
// in constructors
import java.io.*;
class InputFile {
  private BufferedReader in;
  InputFile(String fname) throws Exception {
    try {
      in =
        new BufferedReader(
          new FileReader(fname));
      // Other code that might throw exceptions
    } catch(FileNotFoundException e) {
      System.out.println(
        "Could not open " + fname);
      // Wasn't open, so don't close it
      throw e;
    } catch(Exception e) {
      // All other exceptions must close it
      try {
        in.close();
      } catch(IOException e2) {
        System.out.println(
          "in.close() unsuccessful");
      }
      throw e;
    } finally {
      // Don't close it here!!!
    }
  }
  String getLine() {
    String s;
    try {
      s = in.readLine();
    } catch(IOException e) {
      System.out.println(
        "readLine() unsuccessful");
      s = "failed";
    }
    return s;
  }
  void cleanup() {
    try {
      in.close();
    } catch(IOException e2) {
      System.out.println(
        "in.close() unsuccessful");
    }
  }
}
public class Cleanup {
  public static void main(String[] args) {
    try {
      InputFile in =
        new InputFile("Cleanup.java");
      String s;
      int i = 1;
      while((s = in.getLine()) != null)
        System.out.println(""+ i++ + ": " + s);
      in.cleanup();
    } catch(Exception e) {
      System.out.println(
        "Caught in main, e.printStackTrace()");
      e.printStackTrace();
    }
  }
} ///:~
grazie a chi vorra' aiutarmi
Salute!
NicoWeb
P.S. voi come giudicate Thinking in Java?
--
Per risposte in privato parti dal Salento e togli fino a vento ;-P

 ha scritto nel
messaggio news:Jmdlb.56378$e6.20...@twister2.libero.it...


 esiste il metodo finalize!...;)
ecco, appunto, mica l'ho capito a che serve il finalize. Thinking in Java
asserisce che e' di scarsa utilità, in pratica serve solo a deallocare
memoria allocata tramite codice non java (ossia tramite native methods).
Asserisce che il problema di finalize() è che è legato al garbage collector,
e quindi deve aspettare che il garbage collector entri in azione per essere
eseguito. Quindi non sappiamo _se_ e _quando_ verra' eseguito il nostro
finalize().
Poi scopro che posso usare System.gc() seguito da System.runFinalization()
per lanciare il garbage collector quando voglio! O__________________o
ma allora dov'e' il problema?!??!??! bah!
l'unico problema , a quanto ho capito (non viene detto in modo chiaro), e'
un calo di prestazioni, un rallentamento del codice, ma se io ho pochi
oggetti o cmq pochi che hanno anche il finalize(), allora dov'e' il calo di
prestazioni?
NicoWeb perplesso
Salute!


 ma allora dov'e' il problema?!??!??! bah!
Il problema è lo stesso. La tempistica per l'esecuzione di System.gc() e 
System.runFinalization() è lasciato alla VM, dunque non sappiamo 
_quando_ verranno eseguiti.
Marco
-- 
replay: remove .duh.spam

 ha scritto nel messaggio
news:3f96...@news.swissonline.ch...

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaah!
ora ho capito :-D
Grazie mille per le risposte :-D
Salute!
NicoWeb