View Full Version : [JAVA] "Object obj = null" dentro un blocco try
Qualcuno potrebbe gentilmente spiegare perchè non si deve mettere una istruzione:
Object obj = null;
all'interno di un blocco try se poi nell'istruzione successiva la riassegno subito con un:
obj = (Punto2D) ois.readObject();
dove ois è un ObjectInputStream?
Grazie
Messa così il divieto suona strano. A dirla tutta suonerebbe strano in ogni caso. Non c'è nulla di sintatticamente errato nel dire:
try {
Object obj = null;
obj = (Point2D)ois.readObject();
} catch...
Sia la separazione tra l'inizializzazione a null e l'assegnamento a ois.readObject di obj, sia la conversione esplicita a Point2D prima dell'assegnamento sono superflue ma superfluo non significa errato.
sto seguendo un corso universitario di Java (e OOP in genere), e tra le slide ce n'era una così:
public class Punto2D implements java.io.Serializable {
double x, y;
public Punto2D() {
x = y = 0.0;
}
public Punto2D(double x, double y) {
this.x = x;
this.y = y;
}
public double ascissa() {
return x;
}
public double ordinata() {
return y;
}
}
Altro file:
import java.io.*;
public class ScritturaPunto2D {
public static void main(String args[]) {
FileOutputStream fos = null;
try {
fos = new FileOutputStream("punto.bin");
}
catch(FileNotFoundException e) {
System.out.println("Imposs. aprire il file");
System.exit(1);
}
ObjectOutputStream oos = null;
Punto2D p = new Punto2D(3.14, 7.31);
System.out.println("Scrittura del file");
try {
oos = new ObjectOutputStream(fos);
oos.writeObject(p);
oos.flush();
oos.close();
}
catch(IOException ex) {
System.out.println("Errore di output");
System.exit(2);
}
System.out.println("Fine scrittura del file");
}
}
Altro file:
import java.io.*;
public class LetturaPunto2D {
public static void main(String args[]) {
FileInputStream fis = null;
ObjectInputStream ois = null;
try {
fis = new FileInputStream("punto.bin");
ois = new ObjectInputStream(fis);
}
catch(IOException e) {
System.out.println("Imposs. aprire il file");
System.exit(1);
}
System.out.println("Lettura del file");
Punto2D p = null; //Non metterla dentro il try!!
try {
p = (Punto2D) ois.readObject();
ois.close();
}
catch(IOException ex) {
System.out.println("Errore di input");
System.exit(2);
}
catch(ClassNotFoundException ec) {
System.out.println("Errore di classe-oggetto");
System.exit(3);
}
System.out.println("Punto: [" + p.ascissa() + ","
+ p.ordinata() + "]");
System.out.println("Fine Lettura del file\n\n");
}
}
Ho evidenziato come sia una cosa generalizzata (anche di altre persone su Internet) mettere fuori del try la referenza dell'oggetto a null. Il commento in verdino è quello che mi ha fatto ammattire: cosa si intende con "non metterla"? Perchè non farlo?
Il cast a Punto2D ora dovrebbe essere chiaro: ois.readObject() restituisce un Object.
Magari la cosa è talmente stupida che mi sfugge..
nuovoUtente86
10-07-2007, 21:10
Non è riferito alla instanziazione dell' oggetto ma alla sua dichiarazione,anche perchè di default tutti gli oggetti vanno a null.La questione importante invece è la visibilità della variabile:
una variabile dichiarata all' interno del try ha visibilità solo nel blocco,dichiarata al di fuori ha visibilità globale al metodo. Esempio:
Object o;
try{o=new Object();..........}
o=new Object();
Ok tutto ok
try{Object o;}
o=new Object();
avrai un errore perchè la variabile o all' esterno del try non esiste.
Credo che intenda "non mettere nel blocco dell'enunciato try la dichiarazione della variabile locale p".
L'ambito del nome di una variabile locale (es. quella p) è il blocco (la parte di codice contenuta tra due parentesti graffe) che ne contiene la dichiarazione, a partire dall'enunciato successivo alla dichiarazione.
Se fosse:
try {
Point p = readobject...
} catch(...) {
}
al di fuori del blocco dell'enunciato try il nome "p" non avrebbe significato e non si potrebbe quindi dire, successivamente al try-catch, qualcosa tipo:
System.out.println("Il punto è: " + p);
Il compilatore direbbe "che cavolo è p?"
Dichiarando p fuori dal blocco dell'enunciato try, il suo ambito diviene quello del blocco immediatamente superiore, nel nostro caso il corpo del metodo main. Ogni enunciato successivo alla dichiarazione compreso nel medesimo blocco (sempre il corpo del metodo main) è quindi in grado di fare riferimento a "p" e il nostro System.out.println(...p) avrà un significato per il compilatore.
Credo che sia questo, un problema di ambito e null'altro.
Le variabili locali non sono inizializzate automaticamente. Senza "= null" quel Point2D varrebbe "non inizializzato". Il compilatore stabilisce poi se gli enunciati contenuti nel flusso di esecuzione causino o meno l'inizializzazione della variabile locale prima del suo uso. Se questo controllo fallisce, spara un'eccezione.
Chiaro! Grazie mille!
In effetti avevo pensato quasi a tutto tranne tranne che ad un problema di visibilità.
In che senso p è una variabile locale? Perchè non andrebbe bene semplicemente dichiararla senza inizializzarla null, visto che di default sarebbe null comunque?
Grazie
Se è locale, non è comunque null di default. Una variabile locale non viene inizializzata automaticamente. Deve essere inizializzata esplicitamente. Se il compilatore rileva l'uso della variabile locale prima della sua inizializzazione esplicita, genera un errore.
Una variabile locale è, ad esempio, una variabile dichiarata all'interno del corpo di un metodo.
Nel codice che ho postato non è superfluo inizializzarle tutte null visto che vengono sicuramente riassegnate prima di essere usate?
Il sicuramente che ci vuole è quello stabilito dalle regole del linguaggio di programmazione Java.
Nel nostro caso se p non avesse un inizializzatore esplicito e si verificasse un'eccezione di io in
p = (Point)in.readObject...
avremmo un uso di p (nel System.out.println) a fronte di una variabile locale non inizializzata.
Il fatto che tra la stampa e l'eccezione ci sia un System.exit è irrilevante.
avremmo un uso di p (nel System.out.println) a fronte di una variabile locale non inizializzata.
Il fatto che tra la stampa e l'eccezione ci sia un System.exit è irrilevante.
In questo caso avremmo un'eccezione a run-time oppure non compilerebbe proprio?
G R A Z I E M I L L E.
Sei stato molto gentile.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.